Open Stack

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
>>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack-network-service-apis-generic-vs-specific.png
Type: image/png
Size: 92317 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110210/277c2218/attachment.png>