Open Stack

Thanks for doing the analysis Gary.  Comments inline.

dan

On Tue, Feb 12, 2013 at 1:59 AM, Gary Kotton <gkotton at redhat.com> wrote:

> Hi,
> 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):
> 1. Missing implementations:
>     i. Network deletion - https://github.com/openstack/**
> nova/blob/master/nova/network/**quantumv2/api.py#L433<https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L433>
>     ii. Network disassociation - https://github.com/openstack/**
> nova/blob/master/nova/network/**quantumv2/api.py#L436<https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L436>.
> There is no support for something like this in Quantum.
>

This is intentional, as our model for Nova / Quantum integration was that
networks were managed directly through Quantum, not using Nova's legacy
methods.

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:
https://github.com/openstack/nova/commit/d368afbc74924bb865c90c984a7c5e978fb9473e
.  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. :)



>     iii. Get fixed IP - https://github.com/openstack/**
> nova/blob/master/nova/network/**quantumv2/api.py#L439<https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L439>.
> Is the ID here the port ID?
>

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 (
https://github.com/openstack/nova/commit/ef222bfe6f50d5203f83fa9d2e9071969f814c29),
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.


>     iv. Get VIF's for instance - https://github.com/openstack/**
> nova/blob/master/nova/network/**quantumv2/api.py#L541<https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L541>


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.

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 :)



>
>     v. Get VIF by MAC - https://github.com/openstack/**
> nova/blob/master/nova/network/**quantumv2/api.py#L544<https://github.com/openstack/nova/blob/master/nova/network/quantumv2/api.py#L544>


Not really sure what this is used for.  May be a method not called by any
parts of nova.


>
> 2. Bugs:
>     i. https://bugs.launchpad.net/**nova/+bug/1117770<https://bugs.launchpad.net/nova/+bug/1117770>-
> https://review.openstack.org/#**/c/21414/<https://review.openstack.org/#/c/21414/>
>


>     ii. https://bugs.launchpad.net/**nova/+bug/1122899<https://bugs.launchpad.net/nova/+bug/1122899>-
> https://review.openstack.org/**21751 <https://review.openstack.org/21751>


looks like both just got approved.



>
> Thanks
> Gary
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130212/e897399b/attachment.html>