openstack team mailing list archive

[Romain Lenglet <romain@xxxxxxxxxxx>]

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@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
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> 
> Attachments: 
> - smime.p7s
> 
>