Open Stack

On Tue, Feb 4, 2014 at 12:03 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:

> On Mon, Feb 3, 2014 at 4:59 PM, Christopher Yeoh <cbkyeoh at gmail.com>
> wrote:
> > On Tue, Feb 4, 2014 at 4:32 AM, Joe Gordon <joe.gordon0 at gmail.com>
> wrote:
> >>
> >> On Thu, Jan 30, 2014 at 10:45 PM, Christopher Yeoh <cbkyeoh at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/9b246bc4/attachment.html>