On Mon, Feb 3, 2014 at 10:02 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.

To clarify a bit, the goal here is: a network API that  works with
both nova and neutron without the user knowing which he is using

>> There's a lot to be done in a rather short period of time so any help with
>> patches/reviews would be very welcome.
>> Also I'd appreciate any feedback on what might be considered a reasonable
>> minimal subset of nova-network API support for icehouse so we can better
>> prioritise what gets done first.
>> Regards,
>> Chris
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

OpenStack-dev mailing list

Reply via email to