On 2013年08月08日 13:49, Zhu Bo wrote:
Make sense. If we add nova-network focused api extension, will face the same problem when next api version occurOn 2013年08月07日 21:42, Alex Xu wrote:Nova v2 api will be saved with v3 for some time, I think. Why not just keep neutron api extension in v3? I think people can have enough time to understand the difference between v2 and v3. If we keep api for nova-network in v3, we will still face the same problem when next api version occur or whenOn 2013年08月07日 17:38, John Garbutt wrote:That just describe create instance with multinic, that we will support. Still have problem with action add_fixed_ip and remove_fixed_ip in extension multinic. Those actionmulti-nic added an extra virtual interface on a seprate network, like adding a port:http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.htmlinvoke inject_network_info and reset_network.I think we need to keep a nova-network focused api extension, and a separate neutron focused api extension, because we have not yet removed neutron. It should probably proxy the neutron information still, so people can more easily transition between nova-network and neutron.Sound good, thanks.remove the nova-network.
I agree we should probably slim down the neturon focused api extension. Howerver, it should probably include network-ids and port-ids for each port, if we still support both: nova boot --image <img> --flavor <flavor> --nic net-id=<net1-id> --nic net-id=<net2-id> <vm-name> and this:nova boot --image <img> --flavor <flavor> --nic port-id=<port-id> <vm-name>Yes, we still support those. But why we need network-ids?Longer term, we still need the metadata service to provide networking information, so there will be a nova-api that has to proxy info from neutron, but I agree we should reduce where we can.agree with this. There will be a nova-api that has to proxy info from neutron, but we should reduce where we can.John On 7 August 2013 10:08, Alex Xu <[email protected]> wrote:Hi, guys,Currently we have one core and two extensions that related network in NovaAPI v3.They are ips, attach_interface and multinic. I have two questions for them.The first question is about ips and attach_interface. The below was theindex's response of ips and attach_interface: ips: { "addresses": { "net1": [ { "addr": "10.0.0.8", "mac_addr": "fa:16:3e:c2:0f:aa", "type": "fixed", "version": 4 }, { "addr": "30.0.0.5", "mac_addr": "fa:16:3e:c2:0f:aa", "type": "floating", "version": 4 } ] } } attach_interface: { "interface_attachments": [ { "fixed_ips": [ { "ip_address": "10.0.0.8","subnet_id": "f84f7d51-758c-4a02-a4c9-171ed988a884"} ], "mac_addr": "fa:16:3e:c2:0f:aa", "net_id": "b6ba34f1-5504-4aca-825b-04511c104802", "port_id": "3660380b-0075-4115-be96-f08b41ccdf5d", "port_state": "ACTIVE" } ] }The problem is the responses are similar, but just with different view, andall the information canget from Neutron directly. I think we didn't want to proxy Neutron throughNova. So how aboutwe merge ips and attach_interface into an new extension. The new extensionwill be include the things as below:1. Extend the detail of servers to list the uuid of port. User can get moreinformation from Neutron by port uuid.2. Attach and detach interface that move from extension attach_interface. 3. Extend the creation of servers to support network (The patch already herehttps://review.openstack.org/#/c/36615/)The second question is about multinic. Looking into the code, multinic justadd fixed_ip for server's port. That can be done by Neutron API directly too. But there are inject_network_info and reset_networkin the code. Only xen and vmware's driver implement that function. I'm notfamiliar with xen andvmware, I guess it use guest agent to update the guest network. If I amright, I think we didn't encourage using that way to update guest network.There are api for inject_network_info and reset_networkin extension admin-actions also. I think we can keep them. But can we deletemultinic for V3? Thanks Alex _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
