[openstack-dev] Introducing the new OpenStack service for Containers

Clint Byrum clint at fewbar.com
Fri Nov 22 16:47:13 UTC 2013


Excerpts from Thierry Carrez's message of 2013-11-22 01:50:39 -0800:
> Tim Bell wrote:
> > Can we make sure that the costs for the end users are also considered as
> > part of this ?
> > 
> > -          Configuration management will need further modules
> > -          Dashboard confusion as we get multiple tabs
> > -          Accounting, Block Storage, Networking, Orchestration
> > confusion as the concepts diverge
> > 
> > Is this really a good idea to create another project considering the
> > needs of the whole openstack community ?
> 
> Personally, it will have to prove a really different API and set of use
> cases to justify the cost of a separate project. I'm waiting to see what
> they come up with, but IMHO it's "compute" in both cases. We've seen
> with the libvirt-sandbox discussion that using technology (hypervisor
> vs. container) to draw the line between the use cases is a bit
> over-simplifying the problem.
> 

Agreed, I think it has been over simplified, but that is what you do
when you're not driven by a well understood real use-case, something I
have yet to see from this discussion.

> I don't really want us to create a container service and end up
> implementing the same hypervisor backends than in Nova, just because
> hypervisors can perfectly also be used to serve lightweight
> application-centric workloads. Or the other way around (keep Docker
> support in Nova since you can perfectly run an OS in a container). At
> first glance, extending the Nova API to also cover lightweight
> app-centric use cases would avoid a ton of duplication...
> 

Agreed. There are a few weird things that come to mind though. One of
those is that I imagine users would like to do something like this:

host_id=$(container-thing allocate-host --flavor small  appserver)
db_id=$(container-thing allocate-host --flavor huge dbserver)
app_id=$(container-thing run --host $host_id --image app-image)
proxy_id=$(container-thing run --host $host_id --image proxy-image)
cache_id=$(container-thing run --host $host_id --image cache-image)
db_id=$(container-thing run --host $db_id)

As in, they'd probably like to have VMs spun up and then chopped up
into containers. If this is implemented first inside nova, that may end
up being a rats nest and hard to separate later.  The temptation to use
private API's is really strong. But if it is outside nova, the separation
stays clear and the two can be used without one-another very easily.

> If the main concern is to keep Nova small and manageable, I'd rather rip
> out pieces like nova-network or the scheduler, which are clearly not
> "compute".
> 

Indeed, and those things are under way. :)



More information about the OpenStack-dev mailing list