Open Stack

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.

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).

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

> system agent and go to a VM, then that can be done by attaching the system
> agent to the administrative network - from within the system agent, which
> is the thing that needs this, rather than within Neutron, which doesn't
> really care how you use its networks.  I prefer solutions where other tools
> don't have to make you a special case.