Open Stack

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.

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...

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".

-- 
Thierry Carrez (ttx)