search

LunaNode / lobster

Hourly billing panel for virtual machines
http://lobster.lunanode.com
Other
84 stars 22 forks source link

Docker support #61

Open thetooth opened 8 years ago

thetooth commented 8 years ago

Hi, we're currently working on adding Docker support as an experiment into using this platform for container based hosting(think shared hosting but without the bloat the usual tools bring).

This is an open question to the authors and anyone who would be interested in using it for containers. Once we have a more stable code base(very basic support right now, no bandwidth accounting etc) I'd like to create a PR and merge the VMI module upstream. However. Since lobster is very VM oriented there are a number of things that don't make sense in a container environment. Currently we've changed the language file to reflect the terminology, but that makes it a one or the other type deal.

I'd like to hear some suggestions and comments on what the best way to go about changing the codebase would be.

uakfdotb commented 8 years ago

That sounds very interesting!

Can you give examples of terminology that needs to be updated? Also are there functionality in the module that need to be changed, or anything else other than the language?

thetooth commented 8 years ago

Hi, all occurrences of "VM" would need to be changed to app or container, possibly app is appropriate since it's technology neutral in this case.

Diving deeper into the code I found OverrideCapabilities and friends. This is sufficient to remove VM actions that are not applicable to containers, big thumbs up to whoever wrote that. I'm also looking at the Actions interface, which allows us to add a custom button to the vm info page. This is going to be great for adding console and log pages.

Given what I know at this point, I would say the best course of action would be to break the project into two parts, the lobster library and an example frontend. This way we have the core accounting system which is already technology neutral, and several community forks of the frontend for different application styles.

uakfdotb commented 8 years ago

I think it is possible to keep the front-end application as one version while accommodating this use case; for example, VMs and containers can be referred to as instances instead in the panel. What are some functionalities that you need to implement as extra actions?

By the way, the override capabilities is probably not needed since you can simply opt not to implement the extra interfaces like VMIRename. Lobster will detect that the interface does not implement VMIRename and then not show the rename button.