Open Stack

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.

>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>