<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 December 2013 20:55, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

If it is just a network API, it works the same for everybody. This<br>
makes it simpler, and thus easier to scale out independently of compute<br>
hosts. It is also something we already support and can very easily expand<br>
by just adding a tiny bit of functionality to neutron-metadata-agent.<br>
<br>
In fact we can even push routes via DHCP to send agent traffic through<br>
a different neutron-metadata-agent, so I don't see any issue where we<br>
are piling anything on top of an overstressed single resource. We can<br>
have neutron route this traffic directly to the Heat API which hosts it,<br>
and that can be load balanced and etc. etc. What is the exact scenario<br>
you're trying to avoid?<br></blockquote><div><br></div><div>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.<br>

-- <br></div><div>Ian.<br></div></div></div></div>