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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
