On Mon, Feb 3, 2014 at 4:59 PM, Christopher Yeoh <cbky...@gmail.com> wrote: > 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.
Its unclear to me exactly how hard this would be, we may be able to use much of the nova code to do it. But yes I am concerned about asking neutron to support another API. > > 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'm not too keen in being a proxy for neutron, but this is definitely the easiest option. > > 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. John and I discussed a third possibility: nova-network v3 should be an extension, so the idea was to: Make nova-network API a subset of neturon (instead of them adopting our API we adopt theirs). And we could release v3 without nova network in Icehouse and add the nova-network extension in Juno. > > For big API rewrites I think we can wait for V4 :-) Don't even joke about it. I can't imagine supporting a 3rd version now. > > 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. While I agree with this sentimental we need to make sure we get this right as we will have to live with the consequences for a while. > > Chris > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
