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) _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
