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....@lists.launchpad.net > [mailto:openstack-bounces+dem=ah.jp.nec....@lists.launchpad.ne > t] On Behalf Of 石井 久治 > Sent: Thursday, February 10, 2011 8:48 PM > To: openstack@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....@lists.launchpad.net > >>> > [mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net > >>> ] > >>> On Behalf Of Masanori ITOH > >>> Sent: 31 January 2011 10:31 > >>> To: openstack@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<j...@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....@lists.launchpad.net > >>>> > [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] > >>>> On > >>> Behalf > >>>> Of Thierry Carrez > >>>> Sent: Friday, January 28, 2011 1:52 PM > >>>> To: openstack@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@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~openstack > >>>> More help : https://help.launchpad.net/ListHelp > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mailing list: https://launchpad.net/~openstack > >>>> Post to : openstack@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~openstack > >>>> More help : https://help.launchpad.net/ListHelp > >>> > >>> _______________________________________________ > >>> Mailing list: https://launchpad.net/~openstack > >>> Post to : openstack@lists.launchpad.net > >>> Unsubscribe : https://launchpad.net/~openstack > >>> More help : https://help.launchpad.net/ListHelp > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~openstack > >> Post to : openstack@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~openstack > >> More help : https://help.launchpad.net/ListHelp > >> > > > > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp