Thanks for doing the analysis Gary. Comments inline.<div><br></div><div>dan<br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 1:59 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@redhat.com" target="_blank">gkotton@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
At last nights Quantum meeting I brought up the issue of a number of functions that have not been implemented and just wanted to bring these to peoples attention (I am in the process of trying to fill in the gaps - maybe some do not need to be filled):<br>
1. Missing implementations:<br>
i. Network deletion - <a href="https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L433" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/network/<u></u>quantumv2/api.py#L433</a><br>
ii. Network disassociation - <a href="https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L436" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/network/<u></u>quantumv2/api.py#L436</a>. There is no support for something like this in Quantum.<br>
</blockquote><div><br></div><div>This is intentional, as our model for Nova / Quantum integration was that networks were managed directly through Quantum, not using Nova's legacy methods. </div><div><br></div><div>
The odd thing here is actually that "get" and "list" for networks are implemented in the API. After some digging, it turns out these were added latter without input (to my knowledge) from the Quantum side: <a href="https://github.com/openstack/nova/commit/d368afbc74924bb865c90c984a7c5e978fb9473e">https://github.com/openstack/nova/commit/d368afbc74924bb865c90c984a7c5e978fb9473e</a> . The less than helpful commit message doesn't explain the motivation for this, and there's no associated bug, so you guess is as good as my as to why someone did that. :) </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
iii. Get fixed IP - <a href="https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L439" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/network/<u></u>quantumv2/api.py#L439</a>. Is the ID here the port ID?<br>
</blockquote><div><br></div><div>Looking at the neighboring get_fixed_ip_by_address(), my guess is that the goal of this method is to get the fixed IP based on on an instance-ID. In both cases, such methods a not really compatible with Quantum, as they seem tied to the original ec2 model of one IP per instance, and no overlapping IPs. According to this commit (<a href="https://github.com/openstack/nova/commit/ef222bfe6f50d5203f83fa9d2e9071969f814c29">https://github.com/openstack/nova/commit/ef222bfe6f50d5203f83fa9d2e9071969f814c29</a>), get_fixed_ip_by_address() was implemented by Maru for compatibility with the metadata service. I actually wonder if this is still necessary now in Grizzly, as with Mark's reworking of the metadata stuff to work with overlapping IPs, we should no longer be querying on address. My feeling is that it would be best if the quantum api.py did not implement either method, and that we look into whether we can remove the implementation of get_fixed_ip_by_address() as no longer necessary for metadata. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
iv. Get VIF's for instance - <a href="https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L541" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/network/<u></u>quantumv2/api.py#L541</a></blockquote>
<div><br></div><div>This was used by the following extension: api/openstack/compute/contrib/virtual_interfaces.py . We originally added this extension for the Quantum v1 API, when we had a notion of a "interface-id" in Nova that needed to be "attached" to a quantum port. With Quantum v2, both Nova + Quantum use the quantum port UUID as the ID (when quantum is in use). One could argue that this method should be implemented, if we care about the virtual interfaces extension. </div>
<div><br></div><div>Note: it would be nice if in some way when you did a "show" on a nova server that you could easily see the Quantum port UUIDs associated with that server. This is already possible using a port-list with quantum and then filtering by device_id, but that's pretty cumbersome for users. Another idea would be to add a "convenience command" to the python-quantumclient CLI to list-ports based on a nova server id. I've been meaning to do that for some time now :) </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
v. Get VIF by MAC - <a href="https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L544" target="_blank">https://github.com/openstack/<u></u>nova/blob/master/nova/network/<u></u>quantumv2/api.py#L544</a></blockquote>
<div><br></div><div>Not really sure what this is used for. May be a method not called by any parts of nova. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. Bugs:<br>
i. <a href="https://bugs.launchpad.net/nova/+bug/1117770" target="_blank">https://bugs.launchpad.net/<u></u>nova/+bug/1117770</a> - <a href="https://review.openstack.org/#/c/21414/" target="_blank">https://review.openstack.org/#<u></u>/c/21414/</a> </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
ii. <a href="https://bugs.launchpad.net/nova/+bug/1122899" target="_blank">https://bugs.launchpad.net/<u></u>nova/+bug/1122899</a> - <a href="https://review.openstack.org/21751" target="_blank">https://review.openstack.org/<u></u>21751</a></blockquote>
<div><br></div><div>looks like both just got approved.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Thanks<br>
Gary<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div>
</div>