Open Stack

Excerpts from Scott Moser's message of 2013-12-13 06:28:08 -0800:
> On Tue, 10 Dec 2013, Ian Wells wrote:
> 
> > On 10 December 2013 20:55, Clint Byrum <clint at fewbar.com> wrote:
> >
> > > If it is just a network API, it works the same for everybody. This
> > > makes it simpler, and thus easier to scale out independently of compute
> > > hosts. It is also something we already support and can very easily expand
> > > by just adding a tiny bit of functionality to neutron-metadata-agent.
> > >
> > > In fact we can even push routes via DHCP to send agent traffic through
> > > a different neutron-metadata-agent, so I don't see any issue where we
> > > are piling anything on top of an overstressed single resource. We can
> > > have neutron route this traffic directly to the Heat API which hosts it,
> > > and that can be load balanced and etc. etc. What is the exact scenario
> > > you're trying to avoid?
> > >
> >
> > You may be making even this harder than it needs to be.  You can create
> > multiple networks and attach machines to multiple networks.  Every point so
> > far has been 'why don't we use <idea> as a backdoor into our VM without
> > affecting the VM in any other way' - why can't that just be one more
> > network interface set aside for whatever management  instructions are
> > appropriate?  And then what needs pushing into Neutron is nothing more
> > complex than strong port firewalling to prevent the slaves/minions talking
> > to each other.  If you absolutely must make the communication come from a
> 
> +1
> 
> tcp/ip works *really* well as a communication mechanism.  I'm planning on
> using it to send this email.
> 
> For controlled guests, simply don't break your networking.  Anything that
> could break networking can break /dev/<hypervisor-socket> also.
> 

Who discussed breaking networking?

> Fwiw, we already have an extremely functional "agent" in just about every
> [linux] node in sshd.  Its capable of marshalling just about anything in
> and out of the node. (note, i fully realize there are good reasons for
> more specific agent, lots of them exist).
> 

This was already covered way back in the thread. sshd is a backdoor
agent, and thus undesirable for this purpose. Locking it down is more
effort than adopting an agent which is meant to be limited to specific
tasks.

Also SSH is a push agent, so Savanna/Heat/Trove would have to find the
VM, and reach into it to do things. A pull agent scales well because you
only have to tell the nodes where to pull things from, and then you can
add more things to pull from behind that endpoint without having to
update the nodes.

> I've really never understood "we don't want to rely on networking as a
> transport".
> 

You may have gone to plaid with this one. Not sure what you mean. AFAICT
the direct-to-hypervisor tricks are not exactly popular in this thread.
Were you referring to something else?