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 <d...@nicira.com> wrote: -----
To: Yong Sheng Gong/China/IBM@IBMCN
From: Dan Wendlandt <d...@nicira.com>
Date: 05/30/2012 07:59AM
Cc: Trey Morris <trey.mor...@rackspace.com>, netstack@lists.launchpad.net
Subject: Re: [Netstack] About quantum api v2.0
Hi Yong,
From: Dan Wendlandt <d...@nicira.com>
Date: 05/30/2012 07:59AM
Cc: Trey Morris <trey.mor...@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
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
On Tue, May 29, 2012 at 3:53 PM, Yong Sheng Gong <gong...@cn.ibm.com> wrote:
Hi Dan and tr3buchet,
I see some things in branch 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.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.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 networksif n['network_id'] in requested_networks]# Make sure we only request one allocation per networknetworks = 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 orlen(network_tenant_ids) > 1 or len(network_ids) > 1):# NOTE(jkoelker) Something is screwy, cleanup and errorself._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 <d...@nicira.com> wrote: -----To: Trey Morris <trey.mor...@rackspace.com>
From: Dan Wendlandt <d...@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.0On Tue, May 29, 2012 at 9:07 AM, Trey Morris <trey.mor...@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: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-tr3buchetYup, 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.DanOn Tue, May 29, 2012 at 3:35 AM, Yong Sheng Gong <gong...@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
