<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 4, 2014 at 4:32 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Jan 30, 2014 at 10:45 PM, Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com">cbkyeoh@gmail.com</a>> wrote:<br>

> So with it now looking like nova-network won't go away for the forseable<br>
> future, it looks like we'll want nova-network support in the Nova V3 API<br>
> after all. I've created a blueprint for this work here:<br>
><br>
> <a href="https://blueprints.launchpad.net/nova/+spec/v3-api-restore-nova-network" target="_blank">https://blueprints.launchpad.net/nova/+spec/v3-api-restore-nova-network</a><br>
><br>
> And there is a first pass of what needs to be done here:<br>
><br>
> <a href="https://etherpad.openstack.org/p/NovaV3APINovaNetworkExtensions" target="_blank">https://etherpad.openstack.org/p/NovaV3APINovaNetworkExtensions</a><br>
<br>
</div>From the etherpad:<br>
<br>
"Some of the API only every supported nova-network and not neutron,<br>
others supported both.<br>
I think as a first pass because of limited time we just port them from<br>
V2 as-is. Longer term I think<br>
we should probably remove neutron back-end functionality as we<br>
shouldn't be proxying, but can<br>
decide that later."<br>
<br>
While I like the idea of not proxying neutron, since we are taking the<br>
time to create a new API we should make it clear that this API won't<br>
work when neutron is being used. There have been some nova network<br>
commands that pretend to work even when running neutron (quotas etc).<br>
Perhaps this should be treated as a V3 extension since we don't expect<br>
all deployments to run this API.<br>
<br>
The user befit to proxying neutron is an API that works for both<br>
nova-network and neutron. So a cloud can disable the nova-network API<br>
after the neutron migration instead of  being forced to do so lockstep<br>
with the migration. To continue supporting this perhaps we should see<br>
if we can get neutron to implement its own copy of nova-network v3<br>
API.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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. <br>
<br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>For big API rewrites I think we can wait for V4 :-)<br><br></div><div>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.<br>
</div><div><br>Chris<br></div><br></div></div></div>