<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 4, 2014 at 12:03 PM, 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="HOEnZb"><div class="h5">On Mon, Feb 3, 2014 at 4:59 PM, Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com">cbkyeoh@gmail.com</a>> wrote:<br>

> On Tue, Feb 4, 2014 at 4:32 AM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jan 30, 2014 at 10:45 PM, Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com">cbkyeoh@gmail.com</a>><br>
>> 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>
>> 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>
>><br>
><br>
> So I suspect that asking neutron to support the nova-network API is a bit of<br>
> a big ask. Although I guess it could be done fairly independently from the<br>
> rest of the neutron code (it could I would guess sit on top of their api as<br>
> a translation layer.<br>
<br>
</div></div>Its unclear to me exactly how hard this would be, we may be able to<br>
use much of the nova code to do it. But yes I am concerned about<br>
asking neutron to support another API.<br>
<div class="im"><br>
><br>
> But the much simpler solution would be just to proxy for the neutron service<br>
> only which as you say gives a better transition for user. Fully implementing<br>
> either of these would be Juno timeframe sort of thing though.<br>
<br>
</div>I'm not too keen in being a proxy for neutron, but this is definitely<br>
the easiest option.<br>
<div class="im"><br>
><br>
> I did read a bit of the irc log history discussion on #openstack-nova<br>
> related to this. If I understand what was being said correctly, I do want to<br>
> push back as hard as I can against further delaying the release of the V3<br>
> API in order to design a new nova-network api for the V3 API. I think<br>
> there's always going to be something extra we could wait just one more cycle<br>
> and at some point (which I think is now) we have to go with what we have.<br>
<br>
</div>John and I discussed a third possibility:<br>
<br>
nova-network v3 should be an extension, so the idea was to: Make<br>
nova-network API a subset of neturon (instead of them adopting our API<br>
we adopt theirs). And we could release v3 without nova network in<br>
Icehouse and add the nova-network extension in Juno.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.<br>
<br></div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> For big API rewrites I think we can wait for V4 :-)<br>
<br>
</div>Don't even joke about it. I can't imagine supporting a 3rd version now.<br>
<div class="im"><br>
><br>
> For the moment I'm just going ahead with doing the V2 nova-network port to<br>
> V3 because if I wait any longer for further discussion there simply won't be<br>
> enough time to get the patches submitted before the feature proposal<br>
> deadline.<br>
<br>
</div>While I agree with this sentimental we need to make sure we get this<br>
right as we will have to live with the consequences for a while.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I agree. In the meantime I'll keep working on the port just in case its needed.<br><br>Chris<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
><br>
> Chris<br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>