On Tue, Feb 4, 2014 at 12:03 PM, Joe Gordon <joe.gord...@gmail.com> wrote:
> 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. > > This would actually be my preferred approach if we can get consensus around this. It takes a lot of pressure off this late in the cycle and there's less risk around having to live with a nova-network API in V3 that still has some rough edges around it. I imagine it will be quite a while before we can deprecate the V2 API so IMO going one cycle without nova-network support is not a big thing. > > > 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. > > I agree. In the meantime I'll keep working on the port just in case its needed. Chris > > > > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev