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 <gong...@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 <d...@nicira.com> <d...@nicira.com> wrote: ----- > To: Trey Morris <trey.mor...@rackspace.com> <trey.mor...@rackspace.com> > From: Dan Wendlandt <d...@nicira.com> <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.0 > > > > > On 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: >> 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 <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 > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira, Inc: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
