Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800: > 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. >
Indeed I think it could work, however I think the NIC is unnecessary. Seems likely even with a second NIC that said address will be something like 169.254.169.254 (or the ipv6 equivalent?). If we want to attach that network as a second NIC instead of pushing a route to it via DHCP, that is fine. But I don't think it actually gains much, and the current neutron-metadata-agent already facilitates the conversation between private guests and 169.254.169.254. We just need to make sure we can forward more than port 80 through that. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
