Open Stack

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/907181d7/attachment.html>