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