On Tue, 10 Dec 2013, Ian Wells wrote: > On 10 December 2013 20:55, Clint Byrum <cl...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
