Open Stack

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
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.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131210/c15a7c44/attachment.html>