[Openstack] Network Service for L2/L3 Network Infrastructure blueprint

石井 久治 ishii.hisaharu at lab.ntt.co.jp
Tue Feb 15 07:28:37 UTC 2011


Hello Hiroshi-san

 >> Do you mean that the former API is an interface that is
 >> defined in OpenStack project, and the latter API is
 >> a vendor specific API?
 > My understanding is that yes, that's what he means.

I also think so.

In addition, I feel it is issue that what network functions should be 
defined as generic API, and what network functions should be defined as 
plugin specific API.
How do you think ?

Thanks
Hisaharu Ishii


(2011/02/15 16:18), Romain Lenglet wrote:
> Hi Hiroshi,
> On Tuesday, February 15, 2011 at 15:47, Hiroshi DEMPO wrote:
> Hello Hisaharu san
>>
>> I am not sure about the differences between generic network API and
>> plugin X specific network service API.
>>
>> Do you mean that the former API is an interface that is
>> defined in OpenStack project, and the latter API is
>> a vendor specific API?
>
> My understanding is that yes, that's what he means.
>
> --
> Romain Lenglet
>>
>>
>> Thanks
>> Hiroshi
>>
>>> -----Original Message-----
>>> From: openstack-bounces+dem=ah.jp.nec.com at lists.launchpad.net
>>> [mailto:openstack-bounces+dem=ah.jp.nec.com at lists.launchpad.ne
>>> t] On Behalf Of 石井 久治
>>> Sent: Thursday, February 10, 2011 8:48 PM
>>> To: openstack at lists.launchpad.net
>>> Subject: Re: [Openstack] Network Service for L2/L3 Network
>>> Infrastructure blueprint
>>>
>>> Hi, all
>>>
>>> As we have said before, we have started designing and writing
>>> POC codes of network service.
>>>
>>>> - I know that there were several documents on the new network
>>>> service issue that were locally exchanged so far.
>>>> Why not collecting them into one place and share them
>>> publicly?
>>>
>>> Based on these documents, I created an image of
>>> implementation (attached). And I propose the following set of
>>> methods as the generic network service APIs.
>>> - create_vnic(): vnic_id
>>>   Create a VNIC and return the ID of the created VNIC.
>>> - list_vnics(vm_id): [vnic_id]
>>>   Return the list of vnic_id, where vnic_id is the ID of a VNIC.
>>> - destroy_vnic(vnic_id)
>>>   Remove a VNIC from its VM, given its ID, and destroy it.
>>> - plug(vnic_id, port_id)
>>>   Plug the VNIC with ID vnic_id into the port with ID
>>> port_id managed by this network service.
>>> - unplug(vnic_id)
>>>   Unplug the VNIC from its port, previously plugged by
>>> calling plug().
>>> - create_network(): network_id
>>>   Create a new logical network.
>>> - list_networks(project_id): [network_id]
>>>   Return the list of logical networks available for
>>> project with ID project_id.
>>> - destroy_network(network_id)
>>>   Destroy the logical network with ID network_id.
>>> - create_port(network_id): port_id
>>>   Create a port in the logical network with ID
>>> network_id, and return the port's ID.
>>> - list_ports(network_id): [port_id]
>>>   Return the list of IDs of ports in a network given its ID.
>>> - destroy_port(port_id)
>>>   Destroy port with ID port_id.
>>>
>>> This design is a first draft.
>>> So we would appreciate it if you would give us some comments.
>>>
>>> In parallel with it, we are writing POC codes and uploading
>>> it to "lp:~ntt-pf-lab/nova/network-service".
>>>
>>> Thanks,
>>> Hisaharu Ishii
>>>
>>>
>>> (2011/02/02 19:02), Koji IIDA wrote:
>>>> Hi, all
>>>>
>>>>
>>>> We, NTT PF Lab., also agree to discuss about network service at the
>>>> Diablo DS.
>>>>
>>>> However, we would really like to include network service in
>>> the Diablo
>>>> release because our customers strongly demand this feature. And we
>>>> think that it is quite important to merge new network
>>> service to trunk
>>>> soon after Diablo DS so that every developer can contribute their
>>>> effort based on the new code.
>>>>
>>>> We are planning to provide source code for network service
>>> in a couple
>>>> of weeks. We would appreciate it if you would review it
>>> and give us
>>>> some feedback before the next design summit.
>>>>
>>>> Ewan, thanks for your making new entry at wiki page (*1).
>>> We will also
>>>> post our comments soon.
>>>>
>>>> (*1) http://wiki.openstack.org/NetworkService
>>>>
>>>>
>>>> Thanks,
>>>> Koji Iida
>>>>
>>>>
>>>> (2011/01/31 21:19), Ewan Mellor wrote:
>>>>> I will collect the documents together as you suggest, and
>>> I agree that we need to get the requirements laid out again.
>>>>>
>>>>> Please subscribe to the blueprint on Launchpad -- that way
>>> you will be notified of updates.
>>>>>
>>>>> https://blueprints.launchpad.net/nova/+spec/bexar-network-service
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ewan.
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net
>>> [mailto:openstack-bounces+ewan.mellor=citrix.com at lists.launchpad.net
>>>>>> ]
>>>>>> On Behalf Of Masanori ITOH
>>>>>> Sent: 31 January 2011 10:31
>>>>>> To: openstack at lists.launchpad.net
>>>>>> Subject: Re: [Openstack] Network Service for L2/L3 Network
>>>>>> Infrastructure blueprint
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> We, NTT DATA, also agree with majority of folks.
>>>>>> It's realistic shooting for the the Diablo time frame to have the
>>>>>> new network service.
>>>>>>
>>>>>> Here are my suggestions:
>>>>>>
>>>>>>   - I know that there were several documents on the new network
>>>>>> service issue
>>>>>>   that were locally exchanged so far.
>>>>>>   Why not collecting them into one place and share them
>>> publicly?
>>>>>>
>>>>>>   - I know that the discussion went into a bit
>>> implementation details.
>>>>>>   But now, what about starting the discussion from the
>>> higher level
>>>>>>   design things (again)? Especially, from the
>>> requirements level.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> Masanori
>>>>>>
>>>>>>
>>>>>> From: John Purrier<john at openstack.org>
>>>>>> Subject: Re: [Openstack] Network Service for L2/L3 Network
>>>>>> Infrastructure blueprint
>>>>>> Date: Sat, 29 Jan 2011 06:06:26 +0900
>>>>>>
>>>>>>> You are correct, the networking service will be more
>>> complex than
>>>>>>> the
>>>>>> volume
>>>>>>> service. The existing blueprint is pretty comprehensive,
>>> not only
>>>>>>> encompassing the functionality that exists in today's network
>>>>>>> service
>>>>>> in
>>>>>>> Nova, but also forward looking functionality around flexible
>>>>>>> networking/openvswitch and layer 2 network bridging
>>> between cloud
>>>>>>> deployments.
>>>>>>>
>>>>>>> This will be a longer term project and will serve as the bedrock
>>>>>>> for
>>>>>> many
>>>>>>> future OpenStack capabilities.
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: openstack-bounces+john=openstack.org at lists.launchpad.net
>>> [mailto:openstack-bounces+john=openstack.org at lists.launchpad.net]
>>>>>>> On
>>>>>> Behalf
>>>>>>> Of Thierry Carrez
>>>>>>> Sent: Friday, January 28, 2011 1:52 PM
>>>>>>> To: openstack at lists.launchpad.net
>>>>>>> Subject: Re: [Openstack] Network Service for L2/L3 Network
>>>>>> Infrastructure
>>>>>>> blueprint
>>>>>>>
>>>>>>> John Purrier wrote:
>>>>>>>> Here is the suggestion. It is clear from the response
>>> on the list
>>>>>> that
>>>>>>> refactoring Nova in the Cactus timeframe will be too risky,
>>>>>> particularly as
>>>>>>> we are focusing Cactus on Stability, Reliability, and
>>> Deployability
>>>>>> (along
>>>>>>> with a complete OpenStack API). For Cactus we should leave the
>>>>>> network and
>>>>>>> volume services alone in Nova to minimize destabilizing the code
>>>>>> base. In
>>>>>>> parallel, we can initiate the Network and Volume Service
>>> projects
>>>>>>> in Launchpad and allow the teams that form around these
>>> efforts to
>>>>>>> move
>>>>>> in
>>>>>>> parallel, perhaps seeding their projects from the
>>> existing Nova code.
>>>>>>>>
>>>>>>>> Once we complete Cactus we can have discussions at the Diablo DS
>>>>>> about
>>>>>>> progress these efforts have made and how best to move
>>> forward with
>>>>>> Nova
>>>>>>> integration and determine release targets.
>>>>>>>
>>>>>>> I agree that there is value in starting the proof-of-concept work
>>>>>> around
>>>>>>> the network services, without sacrificing too many developers to
>>>>>>> it,
>>>>>> so
>>>>>>> that a good plan can be presented and discussed at the
>>> Diablo Summit.
>>>>>>>
>>>>>>> If volume sounds relatively simple to me, network sounds
>>>>>> significantly
>>>>>>> more complex (just looking at the code ,network manager code is
>>>>>>> currently used both by nova-compute and nova-network to
>>> modify the
>>>>>> local
>>>>>>> networking stack, so it's more than just handing out IP
>>> addresses
>>>>>>> through an API).
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> --
>>>>>>> Thierry Carrez (ttx)
>>>>>>> Release Manager, OpenStack
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>>> Post to : openstack at lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>>> Post to : openstack at lists.launchpad.net
>>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack at lists.launchpad.net
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack at lists.launchpad.net
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>> Attachments:
>> - smime.p7s
>>
>>
>
>




More information about the Openstack mailing list