I think we had this conversation before some weeks ago. From my perspective I think networking services are normally not considered as first class citizens of the 'Virtual Datacenter'. What Ishimoto-san describes is a Virtual Switch. But networking services in the day-in day-out operations include also DNS management, load balancers, firewalls, VPNs, netflow and others. And this is the main reason to decouple all these services from the Virtual Machine lifecycle: they are a lot of heterogenous network services and some make sense tied to the VM but others make sense tied to the Virtual Datacenter (let's call it the Openstack Project concept). <div>
<br></div><div>The scheduler should handle the network services tied to the VM, but most of the network services are tied to a different kind of resource scheduler, the Virtual Datacenter resources scheduler. This is the orchestrator we are discussing in this thread.</div>
<div><br></div><div>So before adding new virtual resources I think we need some kind of new Orchestrator/Resource scheduler that should handle dependencies between resources (a netflow listener needs a virtual Port of a virtual Switch to be allocated) and pluggable services. What I'm not sure about this kind of orchestration components is if they implement fixed or dynamic workflows. Fixed workflows reduce complexity a lot.</div>
<div><br></div><div>A long email and my poor english... hope you understand it!<br><div><br></div><div>-<br>Diego Parrilla<div><a href="http://nubeblog.com" target="_blank">nubeblog.com</a> | <a href="mailto:nubeblog@nubeblog.com" target="_blank">nubeblog@nubeblog.com</a> | <a href="http://twitter.com/nubeblog" target="_blank">twitter.com/nubeblog</a></div>
<div>+34 649 94 43 29 </div><div><br></div><br>
<br><br><div class="gmail_quote">On Wed, Feb 23, 2011 at 9:47 PM, John Purrier <span dir="ltr"><<a href="mailto:john@openstack.org">john@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
And we are back to the discussion about orchestration... Given the<br>
flexibility of the OpenStack system and the goals of independently<br>
horizontally scaling services I think we will need to address this head on.<br>
#3 is the most difficult, but is also the right answer for the project as we<br>
look forward to adding functionality/services to the mix. This is also where<br>
we can make good use of asynchronous event publication interfaces within<br>
services to ensure maximum efficiency.<br>
<font color="#888888"><br>
John<br>
</font><div class="im"><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">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>] On Behalf<br>
</div><div class="im">Of Vishvananda Ishaya<br>
Sent: Wednesday, February 23, 2011 12:27 PM<br>
To: Ishimoto, Ryu<br>
Cc: <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Subject: Re: [Openstack] Decoupling of Network and Compute services for the<br>
new Network Service design<br>
<br>
</div><div><div></div><div class="h5">Agreed that this is the right way to go.<br>
<br>
We need some sort of supervisor to tell the network to allocate the network<br>
before dispatching a message to compute. I see three possibilities (from<br>
easiest to hardest):<br>
<br>
1. Make the call in /nova/compute/api.py (this code runs on the api host)<br>
2. Make the call in the scheduler (the scheduler then becomes sort of a<br>
supervisor to make sure all setup occurs for a vm to launch)<br>
3. Create a separate compute supervisor that is responsible for managing the<br>
calls to different components<br>
<br>
The easiest seems to be 1, but unfortunately it forces us to wait for the<br>
network allocation to finish before returning to the user which i dislike.<br>
<br>
I think ultimately 3 is probably the best solution, but for now I suggest 2<br>
as a middle ground between easy and best.<br>
<br>
Vish<br>
<br>
On Feb 23, 2011, at 5:29 AM, Ishimoto, Ryu wrote:<br>
<br>
><br>
> Hi everyone,<br>
><br>
> I have been following the discussion regarding the new 'pluggable' network<br>
service design, and wanted to drop in my 2 cents ;-)<br>
><br>
> Looking at the current implementation of Nova, there seems to be a very<br>
strong coupling between compute and network services. That is, tasks that<br>
are done by the network service are executed at the time of VM<br>
instantiation, making the compute code dependent on the network service, and<br>
vice versa. This dependency seems undesirable to me as it adds restrictions<br>
to implementing 'pluggable' network services, which can vary, with many ways<br>
to implement them.<br>
><br>
> Would anyone be opposed to completely separating out the network service<br>
logic from compute? I don't think it's too difficult to accomplish this,<br>
but to do so, it will require that the network service tasks, such as IP<br>
allocation, be executed by the user prior to instantiating the VM.<br>
><br>
> In the new network design(from what I've read up so far), there are<br>
concepts of vNICs, and vPorts, where vNICs are network interfaces that are<br>
associated with the VMs, and vPorts are logical ports that vNICs are plugged<br>
into for network connectivity. If we are to decouple network and compute<br>
services, the steps required for FlatManager networking service would look<br>
something like:<br>
><br>
> 1. Create ports for a network. Each port is associated with an IP address<br>
in this particular case, since it's an IP-based network.<br>
> 2. Create a vNIC<br>
> 3. Plug a vNIC into an avaiable vPort. In this case it just means mapping<br>
this vNIC to an unused IP address.<br>
> 4. Start a VM with this vNIC. vNIC is already mapped to an IP address, so<br>
compute does not have to ask the network service to do any IP allocation.<br>
><br>
> In this simple example, by removing the request for IP allocation from<br>
compute, the network service is no longer needed during the VM<br>
instantiation. While it may require more steps for the network setup in<br>
more complex cases, it would still hold true that, once the vNIC and vPort<br>
are mapped, compute service would not require any network service during the<br>
VM instantiation.<br>
><br>
> IF there is still a need for the compute to access the network service,<br>
there is another way. Currently, the setup of the network<br>
environment(bridge, vlan, etc) is all done by the compute service. With the<br>
new network model, these tasks should either be separated out into a<br>
standalone service('network agent') or at least be separated out into<br>
modules with generic APIs that the network plugin providers can implement.<br>
By doing so, and if we can agree on a rule that the compute service must<br>
always go through the network agent to access the network service, we can<br>
still achieve the separation of compute from network services. Network<br>
agents should have full access to the network service as they are both<br>
implemented by the same plugin provider. Compute would not be aware of the<br>
network agent accessing the network service.<br>
><br>
> With this design, the network service is only tied to the network REST API<br>
and the network agent, both of which are implemented by the plugin<br>
providers. This would allow them to implement their network service without<br>
worrying about the details of the compute service.<br>
><br>
> Please let me know if all this made any sense. :-) Would love to get some<br>
feedbacks.<br>
><br>
> Regards,<br>
> Ryu Ishimoto<br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" 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/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" 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/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" 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></div></div>