openstack team mailing list archive

["Hiroshi DEMPO" <dem@xxxxxxxxxxxxx>]

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?

Thanks
Hiroshi

> -----Original Message-----
> From: openstack-bounces+dem=ah.jp.nec.com@xxxxxxxxxxxxxxxxxxx 
> [mailto:openstack-bounces+dem=ah.jp.nec.com@xxxxxxxxxxxxxxxxxx
> t] On Behalf Of 石井　久治
> Sent: Thursday, February 10, 2011 8:48 PM
> To: openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> >>> 
> [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> >>> ]
> >>> On Behalf Of Masanori ITOH
> >>> Sent: 31 January 2011 10:31
> >>> To: openstack@xxxxxxxxxxxxxxxxxxx
> >>> 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@xxxxxxxxxxxxx>
> >>> 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@xxxxxxxxxxxxxxxxxxx
> >>>> 
> [mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] 
> >>>> On
> >>> Behalf
> >>>> Of Thierry Carrez
> >>>> Sent: Friday, January 28, 2011 1:52 PM
> >>>> To: openstack@xxxxxxxxxxxxxxxxxxx
> >>>> 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@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~openstack
> >>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~openstack
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~openstack
> >>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~openstack
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> 
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature