<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
Not sure what you can do on your vmware backed boxes, but on the kvm compute nodes you can run nova-api-metadata locally. We do this by binding 169.254.169.254 to loopback (technically an non-arping interface would work) on each hypervisor. If I recall correctly,
setting the metadata_server to 127.0.0.1 should add the correct iptables rules when the nova-api-metadata services starts up. You can then block requests for 169.254.169.254 from leaving/entering the server on external interfaces. That should keep all metadata
requests locally to the kvm server. We do this on all of our hypervisors (minus the blocking of metadata from leaving the hypervsior) and are running with flat networks in neutron. Assuming, that keeps all the kvm metadata requests local, you could then
run metadata normally on the network to service the vmware clusters. Assuming that you cant do something similar on those boxes.</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
I haven't done/tried this… but you could also use the extra dhcp options to inject specific and different routes to the metadata service via dhcp/config-drive. Assuming that the traffic gets routed to the metadata server for 169.254.169.254 you could bind
the metadata address to a non-arping interface and everything <span style="font-weight: bold;">
should</span> be fine.</div>
<div>
<div id="">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<div>I<font class="Apple-style-span" color="#000000"><font face="Calibri,sans-serif" style="font-family: Calibri;"> am not sure if vmware supports config drive. If it does, then you could simply not run </font>metadata<font face="Calibri,sans-serif"><font face="Calibri"> services
and use config-drive with cloud init instead. Assuming of course that you are ok with the fact that metadata never changes on config drive once the vm is booted. You can also with a fiarly small patch make it so where config-drive always injects the networking
information into config-drive, even for neutron networks with dhcp enabled. Then statically IP your boxes using config drive vs's dhcp. T</font>h<font face="Calibri">is is what we do. DHCP is for backup only, all of our images are configured with cloud-init
to statically ip from config drive on boot)</font></font></font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">___________________________________________________________________</font></font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Kris Lindgren</font></font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Senior Linux Systems Engineer</font></font></div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri"><span class="Apple-style-span" style="font-size: 14px;">GoDaddy</span></font></font></div>
</div>
</div>
</div>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, December 3, 2015 at 5:29 PM<br>
<span style="font-weight:bold">To: </span>Gilles Mocellin <<a href="mailto:gilles.mocellin@nuagelibre.org">gilles.mocellin@nuagelibre.org</a>><br>
<span style="font-weight:bold">Cc: </span>OpenStack Operators <<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Two regions and so two metadata servers sharing the same VLAN<br>
</div>
<div><br>
</div>
<div>
<div>
<div dir="ltr">Well if that's the case then the metadata wouldn't work for every instance that ARP'ed for the address and got the wrong response first.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Dec 3, 2015 at 3:56 PM, Gilles Mocellin <span dir="ltr">
<<a href="mailto:gilles.mocellin@nuagelibre.org" target="_blank">gilles.mocellin@nuagelibre.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hum, I don't think so. Things like hostname must be only known by the neutron instance of one region...<span class=""><br>
<br>
Le 03/12/2015 00:01, Kevin Benton a écrit :<br>
</span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">Are both metadata servers able to provide metadata for all instances of both sides? If so, why not disable isolated metadata on one of the sides so only one of the DHCP agents will respond?<br>
<br>
<br>
</span>
<div>
<div class="h5">On Thu, Nov 26, 2015 at 6:49 AM, <<a href="mailto:gilles.mocellin@nuagelibre.org" target="_blank">gilles.mocellin@nuagelibre.org</a> <mailto:<a href="mailto:gilles.mocellin@nuagelibre.org" target="_blank">gilles.mocellin@nuagelibre.org</a>>>
wrote:<br>
<br>
Hello stackers !<br>
<br>
Sorry, I also cross-posted that question here<br>
<a href="https://ask.openstack.org/en/question/85195/two-regions-and-so-two-metadata-servers-sharing-the-same-vlan/" rel="noreferrer" target="_blank">
https://ask.openstack.org/en/question/85195/two-regions-and-so-two-metadata-servers-sharing-the-same-vlan/</a><br>
<br>
But I think I can reach a wider audience here.<br>
<br>
So here's my problem.<br>
<br>
I'm facing an non-conventional situation. We're building a two<br>
region Cloud to separate a VMware backend and a KVM one. But both<br>
regions share the same 2 VLANs where we connect all our instances.<br>
<br>
We don't use routers, private network, floating IPs... I've<br>
enabled enable_isolated_metadata, so the metadata IP is inside the<br>
dhcp namespace and there's a static route in the created instances<br>
to it via the dhcp's IP. The two DHCPs could have been a problem<br>
but we will use separate IP ranges, and as Neutron sets static<br>
leases with the instances MAC address, they should not interfere.<br>
<br>
The question I've been asked is whether we will have network<br>
problems with the metadata server IP 169.254.169.254, that will<br>
exist in 2 namepaces on 2 neutron nodes but on the same VLAN. So<br>
they will send ARP packets with different MAC, and will perhaps<br>
perturb access to the metadata URL form the instances.<br>
<br>
Tcpdump shows nothing wrong, but I can't really test now because<br>
we haven't got yet the two regions. What do you think ?<br>
<br>
Of course, the question is not about why we choose to have two<br>
regions. I would have chosen Host Agregates to separate VMware and<br>
KVM, but cinder glance should have been configure the same way.<br>
And with VMware, it's not so feasible.<br>
<br>
Also, if we can, we will try to have separate networks for each<br>
regions, but it involves a lot of bureaucracy here...<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
</div>
</div>
<mailto:<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a>><span class=""><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
<br>
<br>
-- <br>
Kevin Benton<br>
</span></blockquote>
<div class="HOEnZb">
<div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature">
<div>Kevin Benton</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>