<br><br><div class="gmail_quote">2011/2/14 $B@P0f!!5W<#(B <span dir="ltr"><<a href="mailto:ishii.hisaharu@lab.ntt.co.jp">ishii.hisaharu@lab.ntt.co.jp</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Salvatore,<br>
<br>
Thank you for your questions and suggestions.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If I got your design right, the network manager in the current nova implementation (Flat & VLAN) will become plugins. And a plugin can be divided into a "management" component (the one which runs on the network node) and an "agent" (the component running on the compute node). Is that correct?<br>
</blockquote></div>
Yes, it's exactly correct.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
implies that there should be an association between the network entity and the plugin type.<br>
</blockquote></div>
In my current opinion, the network plugins should be possible to be selected per project instead of network. When a project is created, the user should be allowed to specify which type of plugin to use. After that, the user should be allowed to get the plugin to create network with plugin specific parameters. For this reason a column which describes the plugin type should be added to the project table of the DB and the type of plugin should be added to the create_project method as an optional parameter.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm not totally sure about the virtual port concept. Do we really need it? Wouldn't be easier to have a model in which VIF are directly connected to logical switches and virtual port are implicitly assigned?<br>
</blockquote></div>
I also think that your design is simpler.<br>
However for example considering live migration of VM, the concepts of "virtual port" can assure the compute manager that the network environment behind the port will be kept.</blockquote><div><br>+1 for having separate virtual NIC and virtual port concepts.<br>
Those are different kinds of resources:<br>- a virtual NIC is a resource of the host where the VM with that NIC is running, and may be as little as a TAP interface, or as much as a dedicated hardware network interface;<br>
- a virtual port is a network resource, and may correspond to QoS guarantees (e.g. minimum rate, maximum delay, etc.), a given network topology it gives access to, packet filtering settings (iptables-like rules), etc.<br>
One will typically want to control and identify those resources separately.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Finally, have you already got some design ideas concerning how to provide L4/L7 services (for instance firewall, DHCP, DNS, load balancing, etc.) to nova networks?<br>
</blockquote></div>
I'm designing only how to migrate current network model(firewall and DHCP) to the plugin now.<br>
<br>
Cheers,<br>
Hisaharu Ishii<div><div></div><div class="h5"><br>
<br>
<br>
(2011/02/11 1:19), Salvatore Orlando wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Hisaharu,<br>
<br>
Thanks for sharing this design proposal and the POC code.<br>
I will have a look at the code as soon as possible.<br>
At a first glance, I think the design that you are proposing is in line with the goals of the network service blueprint (<a href="http://wiki.openstack.org/NetworkService" target="_blank">http://wiki.openstack.org/NetworkService</a>)<br>
<br>
If I got your design right, the network manager in the current nova implementation (Flat& VLAN) will become plugins. And a plugin can be divided into a "management" component (the one which runs on the network node) and an "agent" (the component running on the compute node). Is that correct?<br>
Also, from your design it seems it should be possible to have different plugins running together in the same deployment. This makes a lot of sense to me, and IMHO, implies that there should be an association between the network entity and the plugin type. When a network is created, the user should be allowed to specify which type of plugin should be handling that network. For this reason I think maybe the create_network API should accept the type of plugin as an optional parameter, in order to route the request to the appropriate network node. If no parameter is provided then the request would be routed to a 'default' network node.<br>
I also noticed you are introducing the concepts of "logical switch" and "virtual port". While I totally agree on the logical switch concept, I'm not totally sure about the virtual port concept. Do we really need it? Wouldn't be easier to have a model in which VIF are directly connected to logical switches and virtual port are implicitly assigned?<br>
<br>
Finally, have you already got some design ideas concerning how to provide L4/L7 services (for instance firewall, DHCP, DNS, load balancing, etc.) to nova networks?<br>
<br>
Cheers,<br>
Salvatore<br>
<br>
-----Original Message-----<br>
From: openstack-bounces+salvatore.orlando=<a href="http://eu.citrix.com" target="_blank">eu.citrix.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a> [mailto:<a href="mailto:openstack-bounces%2Bsalvatore.orlando" target="_blank">openstack-bounces+salvatore.orlando</a>=<a href="http://eu.citrix.com" target="_blank">eu.citrix.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>] On Behalf Of ?? ??<br>
Sent: 10 February 2011 11:48<br>
To: <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Subject: Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint<br>
<br>
Hi, all<br>
<br>
As we have said before, we have started designing and writing POC codes of network service.<br>
<br>
> - I know that there were several documents on the new network<br>
> service issue that were locally exchanged so far.<br>
> Why not collecting them into one place and share them publicly?<br>
<br>
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.<br>
- create_vnic(): vnic_id<br>
Create a VNIC and return the ID of the created VNIC.<br>
- list_vnics(vm_id): [vnic_id]<br>
Return the list of vnic_id, where vnic_id is the ID of a VNIC.<br>
- destroy_vnic(vnic_id)<br>
Remove a VNIC from its VM, given its ID, and destroy it.<br>
- plug(vnic_id, port_id)<br>
Plug the VNIC with ID vnic_id into the port with ID port_id managed by this network service.<br>
- unplug(vnic_id)<br>
Unplug the VNIC from its port, previously plugged by calling plug().<br>
- create_network(): network_id<br>
Create a new logical network.<br>
- list_networks(project_id): [network_id]<br>
Return the list of logical networks available for project with ID project_id.<br>
- destroy_network(network_id)<br>
Destroy the logical network with ID network_id.<br>
- create_port(network_id): port_id<br>
Create a port in the logical network with ID network_id, and return the port's ID.<br>
- list_ports(network_id): [port_id]<br>
Return the list of IDs of ports in a network given its ID.<br>
- destroy_port(port_id)<br>
Destroy port with ID port_id.<br>
<br>
This design is a first draft.<br>
So we would appreciate it if you would give us some comments.<br>
<br>
In parallel with it, we are writing POC codes and uploading it to "lp:~ntt-pf-lab/nova/network-service".<br>
<br>
Thanks,<br>
Hisaharu Ishii<br>
<br>
<br>
(2011/02/02 19:02), Koji IIDA wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi, all<br>
<br>
<br>
We, NTT PF Lab., also agree to discuss about network service at the<br>
Diablo DS.<br>
<br>
However, we would really like to include network service in the Diablo<br>
release because our customers strongly demand this feature. And we<br>
think that it is quite important to merge new network service to trunk<br>
soon after Diablo DS so that every developer can contribute their<br>
effort based on the new code.<br>
<br>
We are planning to provide source code for network service in a couple<br>
of weeks. We would appreciate it if you would review it and give us<br>
some feedback before the next design summit.<br>
<br>
Ewan, thanks for your making new entry at wiki page (*1). We will also<br>
post our comments soon.<br>
<br>
(*1) <a href="http://wiki.openstack.org/NetworkService" target="_blank">http://wiki.openstack.org/NetworkService</a><br>
<br>
<br>
Thanks,<br>
Koji Iida<br>
<br>
<br>
(2011/01/31 21:19), Ewan Mellor wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I will collect the documents together as you suggest, and I agree that we need to get the requirements laid out again.<br>
<br>
Please subscribe to the blueprint on Launchpad -- that way you will be notified of updates.<br>
<br>
<a href="https://blueprints.launchpad.net/nova/+spec/bexar-network-service" target="_blank">https://blueprints.launchpad.net/nova/+spec/bexar-network-service</a><br>
<br>
Thanks,<br>
<br>
Ewan.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
-----Original Message-----<br>
From: openstack-bounces+ewan.mellor=<a href="http://citrix.com" target="_blank">citrix.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a><br>
[mailto:<a href="mailto:openstack-bounces%2Bewan.mellor" target="_blank">openstack-bounces+ewan.mellor</a>=<a href="http://citrix.com" target="_blank">citrix.com</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a><br>
]<br>
On Behalf Of Masanori ITOH<br>
Sent: 31 January 2011 10:31<br>
To: <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Subject: Re: [Openstack] Network Service for L2/L3 Network<br>
Infrastructure blueprint<br>
<br>
Hello,<br>
<br>
We, NTT DATA, also agree with majority of folks.<br>
It's realistic shooting for the the Diablo time frame to have the<br>
new network service.<br>
<br>
Here are my suggestions:<br>
<br>
- I know that there were several documents on the new network<br>
service issue<br>
that were locally exchanged so far.<br>
Why not collecting them into one place and share them publicly?<br>
<br>
- I know that the discussion went into a bit implementation details.<br>
But now, what about starting the discussion from the higher level<br>
design things (again)? Especially, from the requirements level.<br>
<br>
Any thoughts?<br>
<br>
Masanori<br>
<br>
<br>
From: John Purrier<<a href="mailto:john@openstack.org" target="_blank">john@openstack.org</a>><br>
Subject: Re: [Openstack] Network Service for L2/L3 Network<br>
Infrastructure blueprint<br>
Date: Sat, 29 Jan 2011 06:06:26 +0900<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
You are correct, the networking service will be more complex than<br>
the<br>
</blockquote>
volume<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
service. The existing blueprint is pretty comprehensive, not only<br>
encompassing the functionality that exists in today's network<br>
service<br>
</blockquote>
in<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Nova, but also forward looking functionality around flexible<br>
networking/openvswitch and layer 2 network bridging between cloud<br>
deployments.<br>
<br>
This will be a longer term project and will serve as the bedrock<br>
for<br>
</blockquote>
many<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
future OpenStack capabilities.<br>
<br>
John<br>
<br>
-----Original Message-----<br>
From: openstack-bounces+john=<a href="http://openstack.org" target="_blank">openstack.org</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a><br>
[mailto:<a href="mailto:openstack-bounces%2Bjohn" target="_blank">openstack-bounces+john</a>=<a href="http://openstack.org" target="_blank">openstack.org</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>]<br>
On<br>
</blockquote>
Behalf<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Of Thierry Carrez<br>
Sent: Friday, January 28, 2011 1:52 PM<br>
To: <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Subject: Re: [Openstack] Network Service for L2/L3 Network<br>
</blockquote>
Infrastructure<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
blueprint<br>
<br>
John Purrier wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Here is the suggestion. It is clear from the response on the list<br>
</blockquote></blockquote>
that<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
refactoring Nova in the Cactus timeframe will be too risky,<br>
</blockquote>
particularly as<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
we are focusing Cactus on Stability, Reliability, and Deployability<br>
</blockquote>
(along<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
with a complete OpenStack API). For Cactus we should leave the<br>
</blockquote>
network and<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
volume services alone in Nova to minimize destabilizing the code<br>
</blockquote>
base. In<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
parallel, we can initiate the Network and Volume Service projects<br>
in Launchpad and allow the teams that form around these efforts to<br>
move<br>
</blockquote>
in<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
parallel, perhaps seeding their projects from the existing Nova code.<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Once we complete Cactus we can have discussions at the Diablo DS<br>
</blockquote></blockquote>
about<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
progress these efforts have made and how best to move forward with<br>
</blockquote>
Nova<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
integration and determine release targets.<br>
<br>
I agree that there is value in starting the proof-of-concept work<br>
</blockquote>
around<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
the network services, without sacrificing too many developers to<br>
it,<br>
</blockquote>
so<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
that a good plan can be presented and discussed at the Diablo Summit.<br>
<br>
If volume sounds relatively simple to me, network sounds<br>
</blockquote>
significantly<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
more complex (just looking at the code ,network manager code is<br>
currently used both by nova-compute and nova-network to modify the<br>
</blockquote>
local<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
networking stack, so it's more than just handing out IP addresses<br>
through an API).<br>
<br>
Cheers,<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
Release Manager, OpenStack<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br>