Mailing List Archive

About quantum api v2.0

Hi,
We have planned to replace quantum network manager in nova project with quantum api v2.0 calls.
I have found that nova will call following 34 network api methods:
class API(base.Base):
# called in compute manager
def get_instance_nw_info(self, context, instance):
pass

def add_fixed_ip_to_instance(self, context, instance, network_id):
# libvirt does not support
pass

def remove_fixed_ip_from_instance(self, context, instance, address):
# libvirt does not support
"""Removes a fixed ip from instance from specified network."""

args = {'instance_id': instance['id'],
'host': instance['host'],
'address': address}
pass

def deallocate_for_instance(self, context, instance, **kwargs):
"""Deallocates all network structures related to instance."""
args = kwargs
args['instance_id'] = instance['id']
args['project_id'] = instance['project_id']
args['host'] = instance['host']
pass

def allocate_for_instance(self, context, instance, **kwargs):
pass

def setup_networks_on_host(self, context, instance, host=None,
teardown=False):
# setup dhcp info on host
pass



# called in floating_ips controller
def get_fixed_ip(self, context, id):
#fixed_ip_id
pass

def get_floating_ip(self, context, id):
pass

def get_floating_ips_by_project(self, context):
pass

def get_floating_ip_by_address(self, context, address):
pass
def allocate_floating_ip(self, context, pool=None):
pass

def release_floating_ip(self, context, address,
affect_auto_assigned=False):
pass
def disassociate_floating_ip(self, context, address,
affect_auto_assigned=False):
pass

#called in FloatingIPPool
def get_floating_ip_pools(self, context):
pass

#called in get meta handler
def get_fixed_ip_by_address(self, context, address):
pass

#called in FloatingIPDNSEntryController
def get_dns_entries_by_name(self):
pass

def get_dns_entries_by_address(self):
pass

def add_dns_entry(self):
pass

def modify_dns_entry(self):
pass

def delete_dns_entry(self):
pass

#called in FloatingIPDNSDomainController
def get_dns_domains(self):
pass

def create_private_dns_domain(self):
pass
def create_public_dns_domain(self):
pass
def delete_dns_domain(self):
pass


#called in network controller
def get_all(self, context):
pass

def get(self, context, network_uuid):
pass

def delete(self, context, network_uuid):
pass

def disassociate(self, context, network_uuid):
pass
#called in compute api
def validate_networks(self, context, requested_networks):
pass
def get_instance_uuids_by_ip_filter(self, context, filters):
pass
def associate_floating_ip(self, context, floating_address, fixed_address,
affect_auto_assigned=False):
pass
# called in ServerVirtualInterfaceController
def get_vifs_by_instance(self, context, instance):
pass

#unknown
def add_network_to_project(self, context, project_id):
pass
def get_vif_by_mac_address(self, context, mac_address):
pass
def get_floating_ips_by_fixed_address(self, context, fixed_address):
pass

There are some called in compute manager, some called in compute api,
most called in controllers under nova/api/openstack/compute/contrib. Some even are seemingly not called at all.

Our current quantum api is much finer grained compared to the api needed by nova. There seems to be a disparity between them. For example, nova does not need to add a port to a network, plugin an interface api at all. It just needs coarse grained api such as allocate_for_instance and deallocate_for_instance etc.

How do we implement quantum api v2.0? It is fine grained or coarse grained.

Any ideas?
Thanks
Yong Sheng Gong
Re: About quantum api v2.0 [ In reply to ]
Mr. Gong, we've got a lot of work going on in this area and it's rapidly
changing at the moment. We've already written a new network manager that we
use and I'm in the process of removing the network manager piece all
together when using nova with quantum. This work is planned for upstream as
a part of Folsom.

A few (dated) branches you can peruse:
https://github.com/jkoelker/nova/tree/the_deuce
https://github.com/tr3buchet/nova/tree/quantum_api

As to your question about the disparity, quantum isn't written specific to
nova. You can see how we've handled it in the above branches. Let me know
if you have any further questions.

-tr3buchet


On Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

>
> Hi,
> We have planned to replace quantum network manager in nova project with
> quantum api v2.0 calls.
> I have found that nova will call following 34 network api methods:
> class API(base.Base):
> # called in compute manager
> def get_instance_nw_info(self, context, instance):
> pass
>
> def add_fixed_ip_to_instance(self, context, instance, network_id):
> # libvirt does not support
> pass
>
> def remove_fixed_ip_from_instance(self, context, instance, address):
> # libvirt does not support
> """Removes a fixed ip from instance from specified network."""
>
> args = {'instance_id': instance['id'],
> 'host': instance['host'],
> 'address': address}
> pass
>
> def deallocate_for_instance(self, context, instance, **kwargs):
> """Deallocates all network structures related to instance."""
> args = kwargs
> args['instance_id'] = instance['id']
> args['project_id'] = instance['project_id']
> args['host'] = instance['host']
> pass
>
> def allocate_for_instance(self, context, instance, **kwargs):
> pass
>
> def setup_networks_on_host(self, context, instance, host=None,
> teardown=False):
> # setup dhcp info on host
> pass
>
>
>
> # called in floating_ips controller
> def get_fixed_ip(self, context, id):
> #fixed_ip_id
> pass
>
> def get_floating_ip(self, context, id):
> pass
>
> def get_floating_ips_by_project(self, context):
> pass
>
> def get_floating_ip_by_address(self, context, address):
> pass
> def allocate_floating_ip(self, context, pool=None):
> pass
>
> def release_floating_ip(self, context, address,
> affect_auto_assigned=False):
> pass
> def disassociate_floating_ip(self, context, address,
> affect_auto_assigned=False):
> pass
>
> #called in FloatingIPPool
> def get_floating_ip_pools(self, context):
> pass
>
> #called in get meta handler
> def get_fixed_ip_by_address(self, context, address):
> pass
>
> #called in FloatingIPDNSEntryController
> def get_dns_entries_by_name(self):
> pass
>
> def get_dns_entries_by_address(self):
> pass
>
> def add_dns_entry(self):
> pass
>
> def modify_dns_entry(self):
> pass
>
> def delete_dns_entry(self):
> pass
>
> #called in FloatingIPDNSDomainController
> def get_dns_domains(self):
> pass
>
> def create_private_dns_domain(self):
> pass
> def create_public_dns_domain(self):
> pass
> def delete_dns_domain(self):
> pass
>
>
> #called in network controller
> def get_all(self, context):
> pass
>
> def get(self, context, network_uuid):
> pass
>
> def delete(self, context, network_uuid):
> pass
>
> def disassociate(self, context, network_uuid):
> pass
> #called in compute api
> def validate_networks(self, context, requested_networks):
> pass
> def get_instance_uuids_by_ip_filter(self, context, filters):
> pass
> def associate_floating_ip(self, context, floating_address,
> fixed_address,
>
> affect_auto_assigned=False):
> pass
> # called in ServerVirtualInterfaceController
> def get_vifs_by_instance(self, context, instance):
> pass
>
> #unknown
> def add_network_to_project(self, context, project_id):
> pass
> def get_vif_by_mac_address(self, context, mac_address):
> pass
> def get_floating_ips_by_fixed_address(self, context, fixed_address):
> pass
>
> There are some called in compute manager, some called in compute api,
> most called in controllers under nova/api/openstack/compute/contrib.
> Some even are seemingly not called at all.
>
> Our current quantum api is much finer grained compared to the api needed
> by nova. There seems to be a disparity between them. For example, nova does
> not need to add a port to a network, plugin an interface api at all. It
> just needs coarse grained api such as allocate_for_instance and deallocate_for_instance
> etc.
>
> How do we implement quantum api v2.0? It is fine grained or coarse
> grained.
>
> Any ideas?
> Thanks
> Yong Sheng Gong
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>
Re: About quantum api v2.0 [ In reply to ]
On Tue, May 29, 2012 at 9:07 AM, Trey Morris <trey.morris@rackspace.com>wrote:

> Mr. Gong, we've got a lot of work going on in this area and it's rapidly
> changing at the moment. We've already written a new network manager that we
> use and I'm in the process of removing the network manager piece all
> together when using nova with quantum. This work is planned for upstream as
> a part of Folsom.
>
> A few (dated) branches you can peruse:
> https://github.com/jkoelker/nova/tree/the_deuce
> https://github.com/tr3buchet/nova/tree/quantum_api
>
> As to your question about the disparity, quantum isn't written specific to
> nova. You can see how we've handled it in the above branches. Let me know
> if you have any further questions
>

> -tr3buchet
>

Yup, that's correct. Trey's branch covers the logic around VM
allocation/deallocation, which is really all Nova will be responsible for
moving forward (this is inline with the general goal of making Nova focus
on compute, leaving networking and storage to other services). The second
of the branch's does this in a really cool way: by having nova-compute call
quantum directly, rather than having everything proxied through
nova-network. This eliminates the need for nova-network all together when
running Quantum.

Of the other calls you mentioned, floating IPs will be implemented as an
extension to the Quantum v2 API (they are an extension in Nova as well).
The DNS stuff was added more recently to Nova, I believe to automatically
create DNS entries when an instance is created. Vish and I have only
talked about this briefly, but we are not currently planning on
implementing this as part of Quantum. My initial thoughts on this is that
it makes more sense as code that could live outside of "core" Nova or
Quantum and simply consume notifications about instances/ports being
created. Thus, I'd rather focus energy on building a good notifications
mechanism.

Dan


>
> On Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gongysh@cn.ibm.com>wrote:
>
>>
>> Hi,
>> We have planned to replace quantum network manager in nova project with
>> quantum api v2.0 calls.
>> I have found that nova will call following 34 network api methods:
>> class API(base.Base):
>> # called in compute manager
>> def get_instance_nw_info(self, context, instance):
>> pass
>>
>> def add_fixed_ip_to_instance(self, context, instance, network_id):
>> # libvirt does not support
>> pass
>>
>> def remove_fixed_ip_from_instance(self, context, instance, address):
>> # libvirt does not support
>> """Removes a fixed ip from instance from specified network."""
>>
>> args = {'instance_id': instance['id'],
>> 'host': instance['host'],
>> 'address': address}
>> pass
>>
>> def deallocate_for_instance(self, context, instance, **kwargs):
>> """Deallocates all network structures related to instance."""
>> args = kwargs
>> args['instance_id'] = instance['id']
>> args['project_id'] = instance['project_id']
>> args['host'] = instance['host']
>> pass
>>
>> def allocate_for_instance(self, context, instance, **kwargs):
>> pass
>>
>> def setup_networks_on_host(self, context, instance, host=None,
>> teardown=False):
>> # setup dhcp info on host
>> pass
>>
>>
>>
>> # called in floating_ips controller
>> def get_fixed_ip(self, context, id):
>> #fixed_ip_id
>> pass
>>
>> def get_floating_ip(self, context, id):
>> pass
>>
>> def get_floating_ips_by_project(self, context):
>> pass
>>
>> def get_floating_ip_by_address(self, context, address):
>> pass
>> def allocate_floating_ip(self, context, pool=None):
>> pass
>>
>> def release_floating_ip(self, context, address,
>> affect_auto_assigned=False):
>> pass
>> def disassociate_floating_ip(self, context, address,
>> affect_auto_assigned=False):
>> pass
>>
>> #called in FloatingIPPool
>> def get_floating_ip_pools(self, context):
>> pass
>>
>> #called in get meta handler
>> def get_fixed_ip_by_address(self, context, address):
>> pass
>>
>> #called in FloatingIPDNSEntryController
>> def get_dns_entries_by_name(self):
>> pass
>>
>> def get_dns_entries_by_address(self):
>> pass
>>
>> def add_dns_entry(self):
>> pass
>>
>> def modify_dns_entry(self):
>> pass
>>
>> def delete_dns_entry(self):
>> pass
>>
>> #called in FloatingIPDNSDomainController
>> def get_dns_domains(self):
>> pass
>>
>> def create_private_dns_domain(self):
>> pass
>> def create_public_dns_domain(self):
>> pass
>> def delete_dns_domain(self):
>> pass
>>
>>
>> #called in network controller
>> def get_all(self, context):
>> pass
>>
>> def get(self, context, network_uuid):
>> pass
>>
>> def delete(self, context, network_uuid):
>> pass
>>
>> def disassociate(self, context, network_uuid):
>> pass
>> #called in compute api
>> def validate_networks(self, context, requested_networks):
>> pass
>> def get_instance_uuids_by_ip_filter(self, context, filters):
>> pass
>> def associate_floating_ip(self, context, floating_address,
>> fixed_address,
>>
>> affect_auto_assigned=False):
>> pass
>> # called in ServerVirtualInterfaceController
>> def get_vifs_by_instance(self, context, instance):
>> pass
>>
>> #unknown
>> def add_network_to_project(self, context, project_id):
>> pass
>> def get_vif_by_mac_address(self, context, mac_address):
>> pass
>> def get_floating_ips_by_fixed_address(self, context, fixed_address):
>> pass
>>
>> There are some called in compute manager, some called in compute api,
>> most called in controllers under nova/api/openstack/compute/contrib.
>> Some even are seemingly not called at all.
>>
>> Our current quantum api is much finer grained compared to the api needed
>> by nova. There seems to be a disparity between them. For example, nova does
>> not need to add a port to a network, plugin an interface api at all. It
>> just needs coarse grained api such as allocate_for_instance and deallocate_for_instance
>> etc.
>>
>> How do we implement quantum api v2.0? It is fine grained or coarse
>> grained.
>>
>> Any ideas?
>> Thanks
>> Yong Sheng Gong
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: About quantum api v2.0 [ In reply to ]
Hi Dan and tr3buchet,
I see some things in branch https://github.com/tr3buchet/nova/tree/quantum_api"]https://github.com/tr3buchet/nova/tree/quantum_api:
1. compute manager is using a configurable network_api, i.e.
self.network_api = utils.import_object(FLAGS.network_api_class)
instead of self.network_api = network.API().
I think, to use new quantum network api, we should have
network_api_class= https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova"]nova.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network"]network.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2"]quantum2.api.QuantumAPI
in nova.conf.
2. most of methods are implemented by calling multiple api methods exposed by melange and quantum servers
here, since melange will soon be merged into quantum. So we will clear melange connection code then.
And https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova"]nova.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network"]network.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2"]quantum2.api.QuantumAPI
is a wrapper API, it will cause some problems.
Let's look at one method of it:

def allocate_for_instance(self, context, instance, requested_networks=None, availability_zone=None, **kwargs): instance_id = instance['uuid'] rxtx_factor = instance['instance_type']['rxtx_factor'] LOG.debug(_('network allocations for instance %s'), instance_id) tenant_id = instance['project_id'] host = instance['host']
networks = self._get_networks(tenant_id, normalize=False, include_default_tenant=True)
if requested_networks: # pare down networks, to include only those requested # TODO(tr3buchet): handle networks in requested networks which # are not in networks.. raise? networks = [n for n in networks if n['network_id'] in requested_networks]
# Make sure we only request one allocation per network networks = set([(net['network_id'], net['tenant_id']) for net in networks])
networks = [{'id': net[0], 'tenant_id': net[1]} for net in networks] vifs = [] try: vifs = self.m_conn.allocate_for_instance_networks(tenant_id, instance_id, networks) except Exception: LOG.exception(_('Melange allocation failed')) self._clean_up_melange(tenant_id, instance_id, raise_exception=False) for vif in vifs: pairs = []
(ips, network_tenant_ids, network_ids) = \ self._get_ips_and_ids_from_vif(vif)
if (not network_tenant_ids or not network_ids or len(network_tenant_ids) > 1 or len(network_ids) > 1):
# NOTE(jkoelker) Something is screwy, cleanup and error self._clean_up_melange(tenant_id, instance_id)
network_tenant_id = network_tenant_ids.pop() network_id = network_ids.pop()
if FLAGS.quantum_use_port_security: if FLAGS.quantum_port_security_include_link_local: mac = netaddr.EUI(vif['mac_address']) ips.append(str(mac.ipv6_link_local()))
pairs = self._generate_address_pairs(vif, ips)
self.q_conn.create_and_attach_port(network_tenant_id, network_id, vif['id'], vm_id=instance_id, rxtx_factor=rxtx_factor, nova_id=availability_zone, allowed_address_pairs=pairs)Here we called two methods by webservice, It will cause:
1. transaction problem,
They are not in one transaction context, So we have to be careful to maintain the consistency of our system.
2. performance.
We have to go-and-back multiple times for one function needed in nova.

So I think we can implement the nova quantum api on the side of quantum.

Any ideas?


Thanks
Yong Sheng Gong






-----Dan Wendlandt <dan@nicira.com> wrote: -----To: Trey Morris <trey.morris@rackspace.com>
From: Dan Wendlandt <dan@nicira.com>
Date: 05/30/2012 12:46AM
Cc: Yong Sheng Gong/China/IBM@IBMCN, netstack@lists.launchpad.net
Subject: Re: [Netstack] About quantum api v2.0



On Tue, May 29, 2012 at 9:07 AM, Trey Morris <trey.morris@rackspace.com> wrote:
Mr. Gong, we've got a lot of work going on in this area and it's rapidly changing at the moment. We've already written a new network manager that we use and I'm in the process of removing the network manager piece all together when using nova with quantum. This work is planned for upstream as a part of Folsom.
A few (dated) branches you can peruse:https://github.com/jkoelker/nova/tree/the_deuce"]https://github.com/jkoelker/nova/tree/the_deuce https://github.com/tr3buchet/nova/tree/quantum_api"]https://github.com/tr3buchet/nova/tree/quantum_api
As to your question about the disparity, quantum isn't written specific to nova. You can see how we've handled it in the above branches. Let me know if you have any further questions

-tr3buchet

Yup, that's correct. Trey's branch covers the logic around VM allocation/deallocation, which is really all Nova will be responsible for moving forward (this is inline with the general goal of making Nova focus on compute, leaving networking and storage to other services). The second of the branch's does this in a really cool way: by having nova-compute call quantum directly, rather than having everything proxied through nova-network. This eliminates the need for nova-network all together when running Quantum.
Of the other calls you mentioned, floating IPs will be implemented as an extension to the Quantum v2 API (they are an extension in Nova as well). The DNS stuff was added more recently to Nova, I believe to automatically create DNS entries when an instance is created. Vish and I have only talked about this briefly, but we are not currently planning on implementing this as part of Quantum. My initial thoughts on this is that it makes more sense as code that could live outside of "core" Nova or Quantum and simply consume notifications about instances/ports being created. Thus, I'd rather focus energy on building a good notifications mechanism.
Dan


On Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

Hi,
We have planned to replace quantum network manager in nova project with quantum api v2.0 calls.
I have found that nova will call following 34 network api methods:
class API(base.Base):
# called in compute manager
def get_instance_nw_info(self, context, instance):
pass

def add_fixed_ip_to_instance(self, context, instance, network_id):
# libvirt does not support
pass

def remove_fixed_ip_from_instance(self, context, instance, address):
# libvirt does not support
"""Removes a fixed ip from instance from specified network."""

args = {'instance_id': instance['id'],
'host': instance['host'],
'address': address}
pass

def deallocate_for_instance(self, context, instance, **kwargs):
"""Deallocates all network structures related to instance."""
args = kwargs
args['instance_id'] = instance['id']
args['project_id'] = instance['project_id']
args['host'] = instance['host']
pass

def allocate_for_instance(self, context, instance, **kwargs):
pass

def setup_networks_on_host(self, context, instance, host=None,
teardown=False):
# setup dhcp info on host
pass



# called in floating_ips controller
def get_fixed_ip(self, context, id):
#fixed_ip_id
pass

def get_floating_ip(self, context, id):
pass

def get_floating_ips_by_project(self, context):
pass

def get_floating_ip_by_address(self, context, address):
pass
def allocate_floating_ip(self, context, pool=None):
pass

def release_floating_ip(self, context, address,
affect_auto_assigned=False):
pass
def disassociate_floating_ip(self, context, address,
affect_auto_assigned=False):
pass

#called in FloatingIPPool
def get_floating_ip_pools(self, context):
pass

#called in get meta handler
def get_fixed_ip_by_address(self, context, address):
pass

#called in FloatingIPDNSEntryController
def get_dns_entries_by_name(self):
pass

def get_dns_entries_by_address(self):
pass

def add_dns_entry(self):
pass

def modify_dns_entry(self):
pass

def delete_dns_entry(self):
pass

#called in FloatingIPDNSDomainController
def get_dns_domains(self):
pass

def create_private_dns_domain(self):
pass
def create_public_dns_domain(self):
pass
def delete_dns_domain(self):
pass


#called in network controller
def get_all(self, context):
pass

def get(self, context, network_uuid):
pass

def delete(self, context, network_uuid):
pass

def disassociate(self, context, network_uuid):
pass
#called in compute api
def validate_networks(self, context, requested_networks):
pass
def get_instance_uuids_by_ip_filter(self, context, filters):
pass
def associate_floating_ip(self, context, floating_address, fixed_address,
affect_auto_assigned=False):
pass
# called in ServerVirtualInterfaceController
def get_vifs_by_instance(self, context, instance):
pass

#unknown
def add_network_to_project(self, context, project_id):
pass
def get_vif_by_mac_address(self, context, mac_address):
pass
def get_floating_ips_by_fixed_address(self, context, fixed_address):
pass

There are some called in compute manager, some called in compute api,
most called in controllers under nova/api/openstack/compute/contrib. Some even are seemingly not called at all.

Our current quantum api is much finer grained compared to the api needed by nova. There seems to be a disparity between them. For example, nova does not need to add a port to a network, plugin an interface api at all. It just needs coarse grained api such as allocate_for_instance and deallocate_for_instance etc.

How do we implement quantum api v2.0? It is fine grained or coarse grained.

Any ideas?
Thanks
Yong Sheng Gong

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp



--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: About quantum api v2.0 [ In reply to ]
Hi Yong,

Yes, trey is waiting on the new API code, as which point there will no
longer be separate calls to quantum + melange, but rather a single call to
the quantumv2 API.

dan

On Tue, May 29, 2012 at 3:53 PM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

> Hi Dan and tr3buchet,
> I see some things in branch https://github.com/tr3buchet/nova/tree/quantum_api: <https://github.com/tr3buchet/nova/tree/quantum_api>
> 1. compute manager is using a configurable network_api, i.e.
> self.network_api = utils.import_object(FLAGS.network_api_class)
>
> instead of self.network_api = network.API().
> I think, to use new quantum network api, we should have
> network_api_class= nova. <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova>network <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network>.quantum2 <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2>.*api.*QuantumAPI
>
> in nova.conf.
> 2. most of methods are implemented by calling multiple api methods exposed by melange and quantum servers
> here, since melange will soon be merged into quantum. So we will clear melange connection code then.
>
> And nova. <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova>network <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network>.quantum2 <https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2>.*api.*QuantumAPI is a wrapper API, it will cause some problems.
>
> Let's look at one method of it:
>
> def allocate_for_instance(self, context, instance, requested_networks=
> None,
> availability_zone=None, **kwargs):
> instance_id = instance['uuid']
> rxtx_factor = instance['instance_type']['rxtx_factor']
> LOG.debug(_('network allocations for instance %s'), instance_id)
> tenant_id = instance['project_id']
> host = instance['host']
>
> networks = self._get_networks(tenant_id, normalize=False,
> include_default_tenant=True)
>
> if requested_networks:
> # pare down networks, to include only those requested
> # TODO(tr3buchet): handle networks in requested networks which
> # are not in networks.. raise?
> networks = [n for n in networks
> if n['network_id'] in requested_networks]
>
> # Make sure we only request one allocation per network
> networks = set([(net['network_id'],
> net['tenant_id']) for net in networks])
>
> networks = [{'id': net[0],
> 'tenant_id': net[1]} for net in networks]
> vifs = []
> try:
> vifs = self.m_conn.allocate_for_instance_networks(tenant_id,
> instance_id,
> networks)
> except Exception:
> LOG.exception(_('Melange allocation failed'))
> self._clean_up_melange(tenant_id, instance_id,
> raise_exception=False)
> for vif in vifs:
> pairs = []
>
> (ips, network_tenant_ids, network_ids) = \
> self._get_ips_and_ids_from_vif(vif)
>
> if (not network_tenant_ids or not network_ids or
> len(network_tenant_ids) > 1 or len(network_ids) > 1):
>
> # NOTE(jkoelker) Something is screwy, cleanup and error
> self._clean_up_melange(tenant_id, instance_id)
>
> network_tenant_id = network_tenant_ids.pop()
> network_id = network_ids.pop()
>
> if FLAGS.quantum_use_port_security:
> if FLAGS.quantum_port_security_include_link_local:
> mac = netaddr.EUI(vif['mac_address'])
> ips.append(str(mac.ipv6_link_local()))
>
> pairs = self._generate_address_pairs(vif, ips)
>
> self.q_conn.create_and_attach_port(network_tenant_id,
> network_id,
> vif['id'],
> vm_id=instance_id,
> rxtx_factor=rxtx_factor,
> nova_id=availability_zone,
> allowed_address_pairs=pairs
> )
>
> Here we called two methods by webservice, It will cause:
> 1. transaction problem,
> They are not in one transaction context, So we have to be careful to maintain the consistency of our system.
>
> 2. performance.
> We have to go-and-back multiple times for one function needed in nova.
>
> So I think we can implement the nova quantum api on the side of quantum.
>
> Any ideas?
>
>
> Thanks
> Yong Sheng Gong
>
>
>
>
>
>
> -----Dan Wendlandt <dan@nicira.com> <dan@nicira.com> wrote: -----
> To: Trey Morris <trey.morris@rackspace.com> <trey.morris@rackspace.com>
> From: Dan Wendlandt <dan@nicira.com> <dan@nicira.com>
> Date: 05/30/2012 12:46AM
> Cc: Yong Sheng Gong/China/IBM@IBMCN, netstack@lists.launchpad.net
> Subject: Re: [Netstack] About quantum api v2.0
>
>
>
>
> On Tue, May 29, 2012 at 9:07 AM, Trey Morris <trey.morris@rackspace.com>wrote:
>
>> Mr. Gong, we've got a lot of work going on in this area and it's rapidly
>> changing at the moment. We've already written a new network manager that we
>> use and I'm in the process of removing the network manager piece all
>> together when using nova with quantum. This work is planned for upstream as
>> a part of Folsom.
>>
>> A few (dated) branches you can peruse:
>> https://github.com/jkoelker/nova/tree/the_deuce
>> https://github.com/tr3buchet/nova/tree/quantum_api
>>
>> As to your question about the disparity, quantum isn't written specific
>> to nova. You can see how we've handled it in the above branches. Let me
>> know if you have any further questions
>>
>
>> -tr3buchet
>>
>
> Yup, that's correct. Trey's branch covers the logic around VM
> allocation/deallocation, which is really all Nova will be responsible for
> moving forward (this is inline with the general goal of making Nova focus
> on compute, leaving networking and storage to other services). The second
> of the branch's does this in a really cool way: by having nova-compute call
> quantum directly, rather than having everything proxied through
> nova-network. This eliminates the need for nova-network all together when
> running Quantum.
>
> Of the other calls you mentioned, floating IPs will be implemented as an
> extension to the Quantum v2 API (they are an extension in Nova as well).
> The DNS stuff was added more recently to Nova, I believe to automatically
> create DNS entries when an instance is created. Vish and I have only
> talked about this briefly, but we are not currently planning on
> implementing this as part of Quantum. My initial thoughts on this is that
> it makes more sense as code that could live outside of "core" Nova or
> Quantum and simply consume notifications about instances/ports being
> created. Thus, I'd rather focus energy on building a good notifications
> mechanism.
>
> Dan
>
>
>>
>> On Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gongysh@cn.ibm.com>wrote:
>>
>>>
>>> Hi,
>>> We have planned to replace quantum network manager in nova project with
>>> quantum api v2.0 calls.
>>> I have found that nova will call following 34 network api methods:
>>> class API(base.Base):
>>> # called in compute manager
>>> def get_instance_nw_info(self, context, instance):
>>> pass
>>>
>>> def add_fixed_ip_to_instance(self, context, instance, network_id):
>>> # libvirt does not support
>>> pass
>>>
>>> def remove_fixed_ip_from_instance(self, context, instance, address):
>>> # libvirt does not support
>>> """Removes a fixed ip from instance from specified network."""
>>>
>>> args = {'instance_id': instance['id'],
>>> 'host': instance['host'],
>>> 'address': address}
>>> pass
>>>
>>> def deallocate_for_instance(self, context, instance, **kwargs):
>>> """Deallocates all network structures related to instance."""
>>> args = kwargs
>>> args['instance_id'] = instance['id']
>>> args['project_id'] = instance['project_id']
>>> args['host'] = instance['host']
>>> pass
>>>
>>> def allocate_for_instance(self, context, instance, **kwargs):
>>> pass
>>>
>>> def setup_networks_on_host(self, context, instance, host=None,
>>> teardown=False):
>>> # setup dhcp info on host
>>> pass
>>>
>>>
>>>
>>> # called in floating_ips controller
>>> def get_fixed_ip(self, context, id):
>>> #fixed_ip_id
>>> pass
>>>
>>> def get_floating_ip(self, context, id):
>>> pass
>>>
>>> def get_floating_ips_by_project(self, context):
>>> pass
>>>
>>> def get_floating_ip_by_address(self, context, address):
>>> pass
>>> def allocate_floating_ip(self, context, pool=None):
>>> pass
>>>
>>> def release_floating_ip(self, context, address,
>>> affect_auto_assigned=False):
>>> pass
>>> def disassociate_floating_ip(self, context, address,
>>> affect_auto_assigned=False):
>>> pass
>>>
>>> #called in FloatingIPPool
>>> def get_floating_ip_pools(self, context):
>>> pass
>>>
>>> #called in get meta handler
>>> def get_fixed_ip_by_address(self, context, address):
>>> pass
>>>
>>> #called in FloatingIPDNSEntryController
>>> def get_dns_entries_by_name(self):
>>> pass
>>>
>>> def get_dns_entries_by_address(self):
>>> pass
>>>
>>> def add_dns_entry(self):
>>> pass
>>>
>>> def modify_dns_entry(self):
>>> pass
>>>
>>> def delete_dns_entry(self):
>>> pass
>>>
>>> #called in FloatingIPDNSDomainController
>>> def get_dns_domains(self):
>>> pass
>>>
>>> def create_private_dns_domain(self):
>>> pass
>>> def create_public_dns_domain(self):
>>> pass
>>> def delete_dns_domain(self):
>>> pass
>>>
>>>
>>> #called in network controller
>>> def get_all(self, context):
>>> pass
>>>
>>> def get(self, context, network_uuid):
>>> pass
>>>
>>> def delete(self, context, network_uuid):
>>> pass
>>>
>>> def disassociate(self, context, network_uuid):
>>> pass
>>> #called in compute api
>>> def validate_networks(self, context, requested_networks):
>>> pass
>>> def get_instance_uuids_by_ip_filter(self, context, filters):
>>> pass
>>> def associate_floating_ip(self, context, floating_address,
>>> fixed_address,
>>>
>>> affect_auto_assigned=False):
>>> pass
>>> # called in ServerVirtualInterfaceController
>>> def get_vifs_by_instance(self, context, instance):
>>> pass
>>>
>>> #unknown
>>> def add_network_to_project(self, context, project_id):
>>> pass
>>> def get_vif_by_mac_address(self, context, mac_address):
>>> pass
>>> def get_floating_ips_by_fixed_address(self, context, fixed_address):
>>> pass
>>>
>>> There are some called in compute manager, some called in compute api,
>>> most called in controllers under nova/api/openstack/compute/contrib.
>>> Some even are seemingly not called at all.
>>>
>>> Our current quantum api is much finer grained compared to the api needed
>>> by nova. There seems to be a disparity between them. For example, nova does
>>> not need to add a port to a network, plugin an interface api at all. It
>>> just needs coarse grained api such as allocate_for_instance and deallocate_for_instance
>>> etc.
>>>
>>> How do we implement quantum api v2.0? It is fine grained or coarse
>>> grained.
>>>
>>> Any ideas?
>>> Thanks
>>> Yong Sheng Gong
>>>
>>> --
>>> Mailing list: https://launchpad.net/~netstack
>>> Post to : netstack@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~netstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~netstack
>> Post to : netstack@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~netstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: About quantum api v2.0 [ In reply to ]
Hi,
How about the performance and transaction problems?
Can't we consider implementing nova quantum api on the quantum server side?
Regards,
Yong Sheng Gong


-----Dan Wendlandt <dan@nicira.com> wrote: -----To: Yong Sheng Gong/China/IBM@IBMCN
From: Dan Wendlandt <dan@nicira.com>
Date: 05/30/2012 07:59AM
Cc: Trey Morris <trey.morris@rackspace.com>, netstack@lists.launchpad.net
Subject: Re: [Netstack] About quantum api v2.0

Hi Yong,
Yes, trey is waiting on the new API code, as which point there will no longer be separate calls to quantum + melange, but rather a single call to the quantumv2 API.
dan

On Tue, May 29, 2012 at 3:53 PM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:
Hi Dan and tr3buchet,
I see some things in branch https://github.com/tr3buchet/nova/tree/quantum_api"]https://github.com/tr3buchet/nova/tree/quantum_api:


1. compute manager is using a configurable network_api, i.e.
self.network_api = utils.import_object(FLAGS.network_api_class)


instead of self.network_api = network.API().
I think, to use new quantum network api, we should have
network_api_class= https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova"]nova.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network"]network.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2"]quantum2.api.QuantumAPI


in nova.conf.
2. most of methods are implemented by calling multiple api methods exposed by melange and quantum servers
here, since melange will soon be merged into quantum. So we will clear melange connection code then.


And https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova"]nova.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network"]network.https://github.com/tr3buchet/nova/tree/9f4b64d49b27170da5c1a5c19be96d342fc10db3/nova/network/quantum2"]quantum2.api.QuantumAPI
is a wrapper API, it will cause some problems.


Let's look at one method of it:

def allocate_for_instance(self, context, instance, requested_networks=None, availability_zone=None, **kwargs): instance_id = instance['uuid'] rxtx_factor = instance['instance_type']['rxtx_factor'] LOG.debug(_('network allocations for instance %s'), instance_id) tenant_id = instance['project_id'] host = instance['host']
networks = self._get_networks(tenant_id, normalize=False, include_default_tenant=True)
if requested_networks: # pare down networks, to include only those requested # TODO(tr3buchet): handle networks in requested networks which # are not in networks.. raise? networks = [n for n in networks if n['network_id'] in requested_networks]
# Make sure we only request one allocation per network networks = set([(net['network_id'], net['tenant_id']) for net in networks])
networks = [{'id': net[0], 'tenant_id': net[1]} for net in networks] vifs = [] try: vifs = self.m_conn.allocate_for_instance_networks(tenant_id, instance_id, networks) except Exception: LOG.exception(_('Melange allocation failed')) self._clean_up_melange(tenant_id, instance_id, raise_exception=False) for vif in vifs: pairs = []
(ips, network_tenant_ids, network_ids) = \ self._get_ips_and_ids_from_vif(vif)
if (not network_tenant_ids or not network_ids or len(network_tenant_ids) > 1 or len(network_ids) > 1):
# NOTE(jkoelker) Something is screwy, cleanup and error self._clean_up_melange(tenant_id, instance_id)
network_tenant_id = network_tenant_ids.pop() network_id = network_ids.pop()
if FLAGS.quantum_use_port_security: if FLAGS.quantum_port_security_include_link_local: mac = netaddr.EUI(vif['mac_address']) ips.append(str(mac.ipv6_link_local()))
pairs = self._generate_address_pairs(vif, ips)
self.q_conn.create_and_attach_port(network_tenant_id, network_id, vif['id'], vm_id=instance_id, rxtx_factor=rxtx_factor, nova_id=availability_zone, allowed_address_pairs=pairs) Here we called two methods by webservice, It will cause:
1. transaction problem,
They are not in one transaction context, So we have to be careful to maintain the consistency of our system.


2. performance.
We have to go-and-back multiple times for one function needed in nova.

So I think we can implement the nova quantum api on the side of quantum.

Any ideas?




Thanks
Yong Sheng Gong






-----Dan Wendlandt <dan@nicira.com> wrote: ----- To: Trey Morris <trey.morris@rackspace.com>
From: Dan Wendlandt <dan@nicira.com>
Date: 05/30/2012 12:46AM
Cc: Yong Sheng Gong/China/IBM@IBMCN, netstack@lists.launchpad.net
Subject: Re: [Netstack] About quantum api v2.0



On Tue, May 29, 2012 at 9:07 AM, Trey Morris <trey.morris@rackspace.com> wrote:
Mr. Gong, we've got a lot of work going on in this area and it's rapidly changing at the moment. We've already written a new network manager that we use and I'm in the process of removing the network manager piece all together when using nova with quantum. This work is planned for upstream as a part of Folsom.
A few (dated) branches you can peruse:https://github.com/jkoelker/nova/tree/the_deuce"]https://github.com/jkoelker/nova/tree/the_deuce https://github.com/tr3buchet/nova/tree/quantum_api"]https://github.com/tr3buchet/nova/tree/quantum_api
As to your question about the disparity, quantum isn't written specific to nova. You can see how we've handled it in the above branches. Let me know if you have any further questions

-tr3buchet

Yup, that's correct. Trey's branch covers the logic around VM allocation/deallocation, which is really all Nova will be responsible for moving forward (this is inline with the general goal of making Nova focus on compute, leaving networking and storage to other services). The second of the branch's does this in a really cool way: by having nova-compute call quantum directly, rather than having everything proxied through nova-network. This eliminates the need for nova-network all together when running Quantum.
Of the other calls you mentioned, floating IPs will be implemented as an extension to the Quantum v2 API (they are an extension in Nova as well). The DNS stuff was added more recently to Nova, I believe to automatically create DNS entries when an instance is created. Vish and I have only talked about this briefly, but we are not currently planning on implementing this as part of Quantum. My initial thoughts on this is that it makes more sense as code that could live outside of "core" Nova or Quantum and simply consume notifications about instances/ports being created. Thus, I'd rather focus energy on building a good notifications mechanism.
Dan


On Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gongysh@cn.ibm.com> wrote:

Hi,
We have planned to replace quantum network manager in nova project with quantum api v2.0 calls.
I have found that nova will call following 34 network api methods:
class API(base.Base):
# called in compute manager
def get_instance_nw_info(self, context, instance):
pass

def add_fixed_ip_to_instance(self, context, instance, network_id):
# libvirt does not support
pass

def remove_fixed_ip_from_instance(self, context, instance, address):
# libvirt does not support
"""Removes a fixed ip from instance from specified network."""

args = {'instance_id': instance['id'],
'host': instance['host'],
'address': address}
pass

def deallocate_for_instance(self, context, instance, **kwargs):
"""Deallocates all network structures related to instance."""
args = kwargs
args['instance_id'] = instance['id']
args['project_id'] = instance['project_id']
args['host'] = instance['host']
pass

def allocate_for_instance(self, context, instance, **kwargs):
pass

def setup_networks_on_host(self, context, instance, host=None,
teardown=False):
# setup dhcp info on host
pass



# called in floating_ips controller
def get_fixed_ip(self, context, id):
#fixed_ip_id
pass

def get_floating_ip(self, context, id):
pass

def get_floating_ips_by_project(self, context):
pass

def get_floating_ip_by_address(self, context, address):
pass
def allocate_floating_ip(self, context, pool=None):
pass

def release_floating_ip(self, context, address,
affect_auto_assigned=False):
pass
def disassociate_floating_ip(self, context, address,
affect_auto_assigned=False):
pass

#called in FloatingIPPool
def get_floating_ip_pools(self, context):
pass

#called in get meta handler
def get_fixed_ip_by_address(self, context, address):
pass

#called in FloatingIPDNSEntryController
def get_dns_entries_by_name(self):
pass

def get_dns_entries_by_address(self):
pass

def add_dns_entry(self):
pass

def modify_dns_entry(self):
pass

def delete_dns_entry(self):
pass

#called in FloatingIPDNSDomainController
def get_dns_domains(self):
pass

def create_private_dns_domain(self):
pass
def create_public_dns_domain(self):
pass
def delete_dns_domain(self):
pass


#called in network controller
def get_all(self, context):
pass

def get(self, context, network_uuid):
pass

def delete(self, context, network_uuid):
pass

def disassociate(self, context, network_uuid):
pass
#called in compute api
def validate_networks(self, context, requested_networks):
pass
def get_instance_uuids_by_ip_filter(self, context, filters):
pass
def associate_floating_ip(self, context, floating_address, fixed_address,
affect_auto_assigned=False):
pass
# called in ServerVirtualInterfaceController
def get_vifs_by_instance(self, context, instance):
pass

#unknown
def add_network_to_project(self, context, project_id):
pass
def get_vif_by_mac_address(self, context, mac_address):
pass
def get_floating_ips_by_fixed_address(self, context, fixed_address):
pass

There are some called in compute manager, some called in compute api,
most called in controllers under nova/api/openstack/compute/contrib. Some even are seemingly not called at all.

Our current quantum api is much finer grained compared to the api needed by nova. There seems to be a disparity between them. For example, nova does not need to add a port to a network, plugin an interface api at all. It just needs coarse grained api such as allocate_for_instance and deallocate_for_instance etc.

How do we implement quantum api v2.0? It is fine grained or coarse grained.

Any ideas?
Thanks
Yong Sheng Gong

--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp



--
Mailing list: https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/%7Enetstack"]https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~




--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt Nicira, Inc: http://www.nicira.com"]www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~