<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 December 2013 19:48, 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">

Excerpts from Jay Pipes's message of 2013-12-12 10:15:13 -0800:<br>
<div><div class="h5">> On 12/10/2013 03:49 PM, Ian Wells wrote:<br>
> > On 10 December 2013 20:55, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a><br>
> > <mailto:<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>>> wrote:<br>
> I've read through this email thread with quite a bit of curiosity, and I<br>
> have to say what Ian says above makes a lot of sense to me. If Neutron<br>
> can handle the creation of a "management vNIC" that has some associated<br>
> iptables rules governing it that provides a level of security for guest<br>
> <-> host and guest <-> $OpenStackService, then the transport problem<br>
> domain is essentially solved, and Neutron can be happily ignorant (as it<br>
> should be) of any guest agent communication with anything else.<br>
><br>
<br>
</div></div>Indeed I think it could work, however I think the NIC is unnecessary.<br>
<br>
Seems likely even with a second NIC that said address will be something<br>
like 169.254.169.254 (or the ipv6 equivalent?).<br></blockquote><div><br></div><div>There *is* no ipv6 equivalent, which is one standing problem.  Another is that (and admittedly you can quibble about this problem's significance) you need a router on a network to be able to get to 169.254.169.254 - I raise that because the obvious use case for multiple networks is to have a net which is *not* attached to the outside world so that you can layer e.g. a private DB service behind your app servers. <br>

<br></div><div>Neither of these are criticisms of your suggestion as much as they are standing issues with the current architecture.<br>-- <br></div><div>Ian.<br></div><br></div></div></div>