Open Stack

On 12/10/2013 03:49 PM, Ian Wells wrote:
> On 10 December 2013 20:55, Clint Byrum <clint at fewbar.com
> <mailto: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 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.

I've read through this email thread with quite a bit of curiosity, and I 
have to say what Ian says above makes a lot of sense to me. If Neutron 
can handle the creation of a "management vNIC" that has some associated 
iptables rules governing it that provides a level of security for guest 
<-> host and guest <-> $OpenStackService, then the transport problem 
domain is essentially solved, and Neutron can be happily ignorant (as it 
should be) of any guest agent communication with anything else.

Best,
-jay