Proof Of Concept: LXD IDE - Interested?

1

:wave: I write & maintain LXDMosaic a web interface for LXD.

TL;DR Seeking validation & want to know if you / your users would you use a web / electron IDE just for LXDMosiac?

Problem
Sometimes I need to write code in containers / VMS (prod edits, transfer times, bandwidth ETC)

Existing Solution
There isn’t one - not that im aware of.

Nano / vim / vi am I going to set these up for every container? F*ck no.

“But @turtle0x1 just mount .bash_rc / config file / exploit bash like so across hosts & containers” - how about no. I’m not about that level of maintenance in prod for 100’s of containers & users.

Alternatives To Writing “Your” Own IDE
“Write a plug-in for Visual studio / Atom / Sublime / Jetbrains” there is far to many IDE’s for me to write a plug-in for each one & every dev has their own preferences - f*ck them all ill throw “my” hat in the ring.

Proposed Solution
A web / electron IDE designed for each user of LXDMosaic.

Not designed to be a “daily driver” but more useful than traditional “text editors” when you / your users need it.

1
11848Ă—939 42.8 KB

2
21848Ă—939 95.8 KB

Its Missing X / Y
This is a proof of concept, not a finished project.

I want the code / a demo
Not yet - I dont want to waste my time writing a “locking mechanism” (file systems are hardTM) without external vaildation.

LXD / LXDMosaic Isn’t ready
It will be if someone depends on it;

LXD = headed by someone smarter & harder working than I.

LXDMosaic = I can bash at it hard enough to get what’s needed.

Your taking credit for someone else’s work
Yep, its not my text editor and I wouldn’t write one - people far smarter than me already spent their time on that. Other than that I’m working on integrating it for general use with LXDMosaic.

Also heavily inspired by Atom - haven’t looked at the code but spend 99% of my time staring at their screen.

Why Target LXDMosaic & not LXD
Its complicated - I dont work for / with the team so I can only really depend on my own software.

Conclusion
If you suffered through my ranting this far, give me a “:heart:” or a “+1” comment if you would benefit. (not sure how to conduct a poll)

2

You know what I would really really love? An ability to use my midnight commander, and open remote lxc containers directly to move files back and forth like it was a drive. Alternatively, I know how to do with tunneling and samba to a directory, but there has to be a better way. I presently have mc in each container and also use it with ssh on side panel to move files back and forth. But if could somehow mount them?? That would be cool.

3

That is a neat idea! Hmm :thinking:

4

I have a rough idea to address that which I’m hoping we’ll get to work in our next dev cycle (November through April).

Right now file operations are extremely costly and slow as each of them may result in the instance filesystem being mounted, a subprocess spawned (for security), have privileges dropped, attach to the instance and then retrieve or push the file.

It’s frankly amazing that this works as fast as it does today :wink:

My plan is to add a new separate files API which instead relies on websocket. Upon connection, we’d spawn a process inside the instance’s filesystem and that process will be able to perform any filesystem operation we want.
This then allows a client to do batch requests without needing to mount/spawn/unmount for every single one of them on the server side.

My stretch goal then is to add a command inside of lxc, quite likely lxc file mount/unmount which would use that API and go-fuse to mount an instance (local or remote) as a usable filesystem.

1 Like
5

Sounds great! Presently, I do everything via SSH, or FTP. Mounting seems trick right now. I have done it and then they get stuck. Perhaps, a real easy simple way like Lxc map container /var/log /newdrive

The biggest issue I have remains backing up large containers to something I can restore from easily and quickly. I have some containers that are 100gb and it takes so long to copy them, many hours. Worst part these containers can’t be taken down. However, if I could mount the containers as a drive, I could do some rolling backups file per file incremental and it would not be a problem. Presently, I have to manually do it via ssh.