On 11/19/2013 03:46 PM, Robert Collins wrote:
On 16 November 2013 08:31, Joe Gordon <joe.gord...@gmail.com> wrote:
and building on unstable Nova APIs. Anything which we accept is a part
of OpenStack should not get randomly made unusable by one contributor
while other contributors constantly have to scramble to catch up. Either
stuff winds up being broken too often or we stifle progress in Nova
because we're afraid to make breaking changes.
the ceilometer plugin for nova hit this, and had to be scrapped. It hooked
into nova-compute and at one point made nova-compute hang there for minutes
at a time.
I agree, that hooking into our underlying python APIs is a bad idea and a
recipe for disaster. But at the same time I do like having things live in a
separate repo, at the very least until they are mature enough to be pulled
into mainline.
But if we do go with the separate repo solution, what are the issues with
proxying third party APIs on top of OpenStack REST APIs? Using the REST
APIs would mean we have a stable contract for these third party APIs to
consume, and we also get more feedback about fixing our own API at the same
time.
As long as the metadataservice doesn't move out :) - that one I think
is pretty core and we have no native replacement [configdrive is not a
replacement :P].
Slightly off tangent thread.
So we recently moved devstack gate to do con fig drive instead of
metadata service, and life was good (no one really noticed). In what
ways is configdrive insufficient compared to metadata service? And is
that something that we should be tackling?
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
