Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker support #61

Open
thetooth opened this issue Mar 31, 2016 · 3 comments
Open

Docker support #61

thetooth opened this issue Mar 31, 2016 · 3 comments

Comments

@thetooth
Copy link

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
Copy link
Member

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
Copy link
Author

thetooth commented Apr 1, 2016

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants