Russell Bryant wrote: > My view of the outcome of the session was not "it *will* be a new > service". Instead, it was, "we *think* it should be a new service, but > let's do some more investigation to decide for sure". > > The action item from the session was to go off and come up with a > proposal for what a new service would look like. In particular, we > needed a proposal for what the API would look like. With that in hand, > we need to come back and ask the question again of whether a new service > is the right answer.
+1 I can see how a separate service can be a good way to avoid making Nova support container-specific use cases and make it even bigger than it is. However if you end up duplicating most of the code, I'm not sure there would be any net gain. I'm not talking about the base service infrastructure and the scheduler (which are well-known duplication already) but more around specific nova features (metadata/config drive, networking, image handling, etc.) that would apply to VMs and containers alike. So it would be great to come out of this first round of analysis with a plan detailing how different (and how similar) from nova that new service would be, and how much code duplication is to be expected. -- Thierry Carrez (ttx) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
