<div class="gmail_quote">On Wed, May 30, 2012 at 4:35 PM, George Mihaiescu <span dir="ltr"><<a href="mailto:George.Mihaiescu@q9.com" target="_blank">George.Mihaiescu@q9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All the flags are very well documented (but they are a many :)<br>
<br>
<a href="http://docs.openstack.org/trunk/openstack-compute/admin/content/compute-options-reference.html" target="_blank">http://docs.openstack.org/trunk/openstack-compute/admin/content/compute-options-reference.html</a></blockquote>
<div><br></div><div>Hey,</div><div><br></div><div>I knew this page, and while browsing over it, I did not pay that much attention to absolutely every line,</div><div>especially where the word "metadata" confused me a bit, and did not hint me, that it actually</div>
<div>meant the "nova-api"-service but some kind of I-don't-know-metadata-service :-)</div><div><br></div><div>Although, I find the few words in that (and other) line(s) a bit too... few - from a newbie-user's point of view.</div>
<div><br></div><div>All I wanted to propose, is, to highlight what to care about in a multi-node setup a bit more, just like </div><div>everyone talks about that the controller node is kind of central and at least contains</div>
<div>the nova-scheduler service, maybe nova-cert, nova-objectstore, but I found no document so far in really</div><div>highlighting waht services are meant to run where, and how to configure their IPs (just like "metadata"</div>
<div>was not clear enough to me to be equal to "nova-api").</div><div><br></div><div>Best regards,</div><div>Christian Parpart. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
George<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:openstack-operators-bounces@lists.openstack.org">openstack-operators-bounces@lists.openstack.org</a> [mailto:<a href="mailto:openstack-operators-bounces@lists.openstack.org">openstack-operators-bounces@lists.openstack.org</a>] On Behalf Of <a href="mailto:openstack-operators-request@lists.openstack.org">openstack-operators-request@lists.openstack.org</a><br>
Sent: Wednesday, May 30, 2012 8:00 AM<br>
To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
Subject: Openstack-operators Digest, Vol 19, Issue 59<br>
<br>
Send Openstack-operators mailing list submissions to<br>
<a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-operators-request@lists.openstack.org">openstack-operators-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-operators-owner@lists.openstack.org">openstack-operators-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openstack-operators digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: cloud-init:169.254.169.254 to time out / refuse<br>
connections (Dan Wendlandt)<br>
2. Re: cloud-init:169.254.169.254 to time out / refuse<br>
connections (Christian Parpart)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 29 May 2012 17:06:20 -0700<br>
From: Dan Wendlandt <<a href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
To: Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>><br>
Cc: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
Subject: Re: [Openstack-operators] cloud-init:169.254.169.254 to time<br>
out / refuse connections<br>
Message-ID:<br>
<CA+0XJm-yRVMOZocN1nmvCHztEA4QhgF1WWd3s-JbXiXUmi=<a href="mailto:Tnw@mail.gmail.com">Tnw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
the flag metadata_host (in nova/flags.py) defaults to the IP address of the<br>
localhost, so nova-network will DNAT to its own IP unless you override<br>
metadata_host in your nova.conf<br>
<br>
Dan<br>
<br>
On Tue, May 29, 2012 at 4:28 PM, Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>> wrote:<br>
<br>
> On Tue, May 29, 2012 at 2:47 PM, Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>>wrote:<br>
><br>
>> Hey all,<br>
>><br>
>> This 169.254.169.254 is driving me crazy. I read a few things already<br>
>> about that suspcisious IP address, however,<br>
>> I always get either a few:<br>
>><br>
>> 2012-05-29 12:22:40,831 - util.py[WARNING]: '<br>
>> <a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed<br>
>> [50/120s]: url error [timed out]<br>
>><br>
>> or I'll get tons of:<br>
>><br>
>> 2012-05-29 12:19:38,049 - util.py[WARNING]: '<br>
>> <a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed<br>
>> [113/120s]: url error [[Errno 111] Connection refused]<br>
>><br>
>> when instantiating a new VM.<br>
>><br>
>> My setup is as follows:<br>
>><br>
>> "production" network: <a href="http://10.10.40.0/21" target="_blank">10.10.40.0/21</a><br>
>> management network (physical nodes, switches, PDUs, ...) <a href="http://10.10.0.0/19" target="_blank">10.10.0.0/19</a><br>
>><br>
>> nova-network: (we're not in multi_host mode)<br>
>> - eth0: 10.10.30.4<br>
>><br>
>> controller (api, scheduler, etc, also compute-1 node):<br>
>> - eth0: 10.10.30.190<br>
>><br>
>> compute-2:<br>
>> - eth0: 10.10.30.191<br>
>><br>
>> compute-3:<br>
>> - eth0: 10.10.30.192<br>
>><br>
>> Now, since the 169.254.169.254 is just an artificial IP, to be NAT'ed to<br>
>> the right host via iptables, I did a quick check,<br>
>> and tcp/80 seems to redirect to the nova-api instance at port 8775.<br>
>><br>
>> So here's my question:<br>
>> On which physical nodes is this iptables rule expected, Just nova-network<br>
>> or on every compute node? (and how to fix my above situation?)<br>
>><br>
>> I'm asking because I found the DNAT rule on the dedicated network node<br>
>> but also compute-1 node (which is also the controller node, with api,<br>
>> scheduler, etc) but not on compute-3 nor on compute-3 node - regardless of<br>
>> my issue, this doesn't feel right.<br>
>><br>
><br>
> Hey,<br>
><br>
> for the latter case (ECONNREFUSED) I believe I have an answer, but not why<br>
> it is set up this way:<br>
><br>
> root@nova-network-node:/etc/nova# iptables -t nat -L -vn | grep -n3<br>
> 169.254.169.254<br>
> 26-<br>
> 27-Chain nova-network-PREROUTING (1 references)<br>
> 28- pkts bytes target prot opt in out source<br>
> destination<br>
> 29: 33 1980 DNAT tcp -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
> 169.254.169.254 tcp dpt:80 to:<a href="http://10.10.40.1:8775" target="_blank">10.10.40.1:8775</a><br>
> 30- 0 0 DNAT udp -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
> 10.10.40.1 udp dpt:1000 to:<a href="http://10.10.40.2:1194" target="_blank">10.10.40.2:1194</a><br>
> 31-<br>
><br>
> This shows, that the suspicious IP address is routed to 10.10.40.1:8875where this IP<br>
> is the host itself and not the nova-api node's IP.<br>
><br>
> AFAIK nova-api is just to be installed onto a single node, that is, the<br>
> controller node, so I wonder<br>
> why nova-network seems to create a DNAT rule for nova-api to its own host<br>
> instead to the cloud controller's IP.<br>
><br>
> I checked my nova.conf, and while there is no direct entry for what IP to<br>
> use for node-api, I at least<br>
> see, that cc_host is set to the proper IP (10.10.30.190).<br>
><br>
> So long,<br>
> Christian Parpart.<br>
><br>
><br>
> _______________________________________________<br>
> Openstack-operators mailing list<br>
> <a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
><br>
<br>
<br>
--<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt<br>
Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20120529/1ed8c810/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20120529/1ed8c810/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 30 May 2012 09:14:38 +0200<br>
From: Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>><br>
To: Dan Wendlandt <<a href="mailto:dan@nicira.com">dan@nicira.com</a>><br>
Cc: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
Subject: Re: [Openstack-operators] cloud-init:169.254.169.254 to time<br>
out / refuse connections<br>
Message-ID:<br>
<CA+qvzFM0Wv=<a href="mailto:iAFBSDSZ86BMkLW-M5f4wULRtDAWc4LP8sELT3A@mail.gmail.com">iAFBSDSZ86BMkLW-M5f4wULRtDAWc4LP8sELT3A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
We should improve the docs regarding multi host setups and this flag to<br>
explicitely state that.<br>
<br>
I found the solution by accident and out of my curiosity. :-)<br>
<br>
Regards,<br>
Christian Parpart.<br>
Am 30.05.2012 02:06 schrieb "Dan Wendlandt" <<a href="mailto:dan@nicira.com">dan@nicira.com</a>>:<br>
<br>
> the flag metadata_host (in nova/flags.py) defaults to the IP address of<br>
> the localhost, so nova-network will DNAT to its own IP unless you override<br>
> metadata_host in your nova.conf<br>
><br>
> Dan<br>
><br>
> On Tue, May 29, 2012 at 4:28 PM, Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>>wrote:<br>
><br>
>> On Tue, May 29, 2012 at 2:47 PM, Christian Parpart <<a href="mailto:trapni@gmail.com">trapni@gmail.com</a>>wrote:<br>
>><br>
>>> Hey all,<br>
>>><br>
>>> This 169.254.169.254 is driving me crazy. I read a few things already<br>
>>> about that suspcisious IP address, however,<br>
>>> I always get either a few:<br>
>>><br>
>>> 2012-05-29 12:22:40,831 - util.py[WARNING]: '<br>
>>> <a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed<br>
>>> [50/120s]: url error [timed out]<br>
>>><br>
>>> or I'll get tons of:<br>
>>><br>
>>> 2012-05-29 12:19:38,049 - util.py[WARNING]: '<br>
>>> <a href="http://169.254.169.254/2009-04-04/meta-data/instance-id" target="_blank">http://169.254.169.254/2009-04-04/meta-data/instance-id</a>' failed<br>
>>> [113/120s]: url error [[Errno 111] Connection refused]<br>
>>><br>
>>> when instantiating a new VM.<br>
>>><br>
>>> My setup is as follows:<br>
>>><br>
>>> "production" network: <a href="http://10.10.40.0/21" target="_blank">10.10.40.0/21</a><br>
>>> management network (physical nodes, switches, PDUs, ...) <a href="http://10.10.0.0/19" target="_blank">10.10.0.0/19</a><br>
>>><br>
>>> nova-network: (we're not in multi_host mode)<br>
>>> - eth0: 10.10.30.4<br>
>>><br>
>>> controller (api, scheduler, etc, also compute-1 node):<br>
>>> - eth0: 10.10.30.190<br>
>>><br>
>>> compute-2:<br>
>>> - eth0: 10.10.30.191<br>
>>><br>
>>> compute-3:<br>
>>> - eth0: 10.10.30.192<br>
>>><br>
>>> Now, since the 169.254.169.254 is just an artificial IP, to be NAT'ed to<br>
>>> the right host via iptables, I did a quick check,<br>
>>> and tcp/80 seems to redirect to the nova-api instance at port 8775.<br>
>>><br>
>>> So here's my question:<br>
>>> On which physical nodes is this iptables rule expected, Just<br>
>>> nova-network or on every compute node? (and how to fix my above situation?)<br>
>>><br>
>>> I'm asking because I found the DNAT rule on the dedicated network node<br>
>>> but also compute-1 node (which is also the controller node, with api,<br>
>>> scheduler, etc) but not on compute-3 nor on compute-3 node - regardless of<br>
>>> my issue, this doesn't feel right.<br>
>>><br>
>><br>
>> Hey,<br>
>><br>
>> for the latter case (ECONNREFUSED) I believe I have an answer, but not<br>
>> why it is set up this way:<br>
>><br>
>> root@nova-network-node:/etc/nova# iptables -t nat -L -vn | grep -n3<br>
>> 169.254.169.254<br>
>> 26-<br>
>> 27-Chain nova-network-PREROUTING (1 references)<br>
>> 28- pkts bytes target prot opt in out source<br>
>> destination<br>
>> 29: 33 1980 DNAT tcp -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
>> 169.254.169.254 tcp dpt:80 to:<a href="http://10.10.40.1:8775" target="_blank">10.10.40.1:8775</a><br>
>> 30- 0 0 DNAT udp -- * * <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a><br>
>> 10.10.40.1 udp dpt:1000 to:<a href="http://10.10.40.2:1194" target="_blank">10.10.40.2:1194</a><br>
>> 31-<br>
>><br>
>> This shows, that the suspicious IP address is routed to 10.10.40.1:8875where this IP<br>
>> is the host itself and not the nova-api node's IP.<br>
>><br>
>> AFAIK nova-api is just to be installed onto a single node, that is, the<br>
>> controller node, so I wonder<br>
>> why nova-network seems to create a DNAT rule for nova-api to its own host<br>
>> instead to the cloud controller's IP.<br>
>><br>
>> I checked my nova.conf, and while there is no direct entry for what IP to<br>
>> use for node-api, I at least<br>
>> see, that cc_host is set to the proper IP (10.10.30.190).<br>
>><br>
>> So long,<br>
>> Christian Parpart.<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Openstack-operators mailing list<br>
>> <a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>><br>
><br>
><br>
> --<br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
> Dan Wendlandt<br>
> Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
> twitter: danwendlandt<br>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-operators/attachments/20120530/84c9ac61/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/attachments/20120530/84c9ac61/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Openstack-operators mailing list<br>
<a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
End of Openstack-operators Digest, Vol 19, Issue 59<br>
***************************************************<br>
_______________________________________________<br>
Openstack-operators mailing list<br>
<a href="mailto:Openstack-operators@lists.openstack.org">Openstack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br>