On Tue, Feb 4, 2014 at 4:32 AM, Joe Gordon <joe.gord...@gmail.com> wrote:
> On Thu, Jan 30, 2014 at 10:45 PM, Christopher Yeoh <cbky...@gmail.com> > wrote: > > So with it now looking like nova-network won't go away for the forseable > > future, it looks like we'll want nova-network support in the Nova V3 API > > after all. I've created a blueprint for this work here: > > > > https://blueprints.launchpad.net/nova/+spec/v3-api-restore-nova-network > > > > And there is a first pass of what needs to be done here: > > > > https://etherpad.openstack.org/p/NovaV3APINovaNetworkExtensions > > From the etherpad: > > "Some of the API only every supported nova-network and not neutron, > others supported both. > I think as a first pass because of limited time we just port them from > V2 as-is. Longer term I think > we should probably remove neutron back-end functionality as we > shouldn't be proxying, but can > decide that later." > > While I like the idea of not proxying neutron, since we are taking the > time to create a new API we should make it clear that this API won't > work when neutron is being used. There have been some nova network > commands that pretend to work even when running neutron (quotas etc). > Perhaps this should be treated as a V3 extension since we don't expect > all deployments to run this API. > > The user befit to proxying neutron is an API that works for both > nova-network and neutron. So a cloud can disable the nova-network API > after the neutron migration instead of being forced to do so lockstep > with the migration. To continue supporting this perhaps we should see > if we can get neutron to implement its own copy of nova-network v3 > API. > > So I suspect that asking neutron to support the nova-network API is a bit of a big ask. Although I guess it could be done fairly independently from the rest of the neutron code (it could I would guess sit on top of their api as a translation layer. But the much simpler solution would be just to proxy for the neutron service only which as you say gives a better transition for user. Fully implementing either of these would be Juno timeframe sort of thing though. I did read a bit of the irc log history discussion on #openstack-nova related to this. If I understand what was being said correctly, I do want to push back as hard as I can against further delaying the release of the V3 API in order to design a new nova-network api for the V3 API. I think there's always going to be something extra we could wait just one more cycle and at some point (which I think is now) we have to go with what we have. For big API rewrites I think we can wait for V4 :-) For the moment I'm just going ahead with doing the V2 nova-network port to V3 because if I wait any longer for further discussion there simply won't be enough time to get the patches submitted before the feature proposal deadline. Chris
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
