[openstack-dev] [Nova] Network stuff in Nova API v3

Alex Xu xuhj at linux.vnet.ibm.com
Mon Aug 12 07:59:47 UTC 2013


On 2013年08月08日 13:49, Zhu Bo wrote:
> On 2013年08月07日 21:42, Alex Xu wrote:
>> On 2013年08月07日 17:38, John Garbutt wrote:
>>> multi-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.html 
>>>
>> 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 action
>> invoke 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.
> 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 when
> remove the nova-network.
Make sense. If we add nova-network focused api extension, will face the 
same problem when next api version occur
>>> 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 <xuhj at linux.vnet.ibm.com> wrote:
>>>> Hi, guys,
>>>>
>>>> Currently we have one core and two extensions that related network 
>>>> in Nova
>>>> API 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 
>>>> the
>>>> index'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,  and
>>>> all the information can
>>>> get from Neutron directly. I think we didn't want to proxy Neutron 
>>>> through
>>>> Nova. So how about
>>>> we merge ips and attach_interface into an new extension. The new 
>>>> extension
>>>> will be include the
>>>> things as below:
>>>> 1. Extend the detail of servers to list the uuid of port. User can 
>>>> get more
>>>> information 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 here
>>>> https://review.openstack.org/#/c/36615/)
>>>>
>>>> The second question is about multinic. Looking into the code, 
>>>> multinic just
>>>> add fixed_ip for server's port.
>>>> That can be done by Neutron API directly too. But there are
>>>> inject_network_info and reset_network
>>>> in the code. Only xen and vmware's driver implement that function. 
>>>> I'm not
>>>> familiar with xen and
>>>> vmware, I guess it use guest agent to update the guest network. If 
>>>> I am
>>>> right, I think we didn't
>>>> encourage using that way to update guest network.There are api for
>>>> inject_network_info and reset_network
>>>> in extension admin-actions also. I think we can keep them. But can 
>>>> we delete
>>>> multinic for V3?
>>>>
>>>> Thanks
>>>> Alex
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>




More information about the OpenStack-dev mailing list