← Back to team overview

openstack team mailing list archive

  1. openstack team
  2. Mailing list archive
  3. Message #00524

Re: Network Service for L2/L3 Network Infrastructure blueprint

  Thread Previous • Date Previous • • Thread Next 
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: openstack-network-service-apis-generic-vs-specific.png
Description: PNG image

Follow ups

References

  Thread Previous • Date Previous • • Thread Next