openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #22091
Re: Openstack Metadata Service
thanks will try that asap
Regards,
Pranav
On Tue, Mar 19, 2013 at 8:53 PM, bruno sendas <bsendas@xxxxxxxxx> wrote:
> Hi,
>
> I had tried every sollution posted on the openstack archives and it simply
> wouldn't work.
> Until I had the wrong idea and installed the nova-api-metadata on the
> controller node and it removed the nova-api, which corrupted the openstack
> deployment. So when I re-installed all the nova components (the
> nova-api-metadata was removed), one reboot later and the metadata server
> was running. :)))
>
> Also, I added a route to the Private Network ( for the VM) using the
> router external gateway.
>
> The problem must have been from a bad installation of nova-api int the
> controller node.
>
> best regards,
> Bruno
>
>
> 2013/3/18 Pranav <pps.pranav@xxxxxxxxx>
>
>> I think this should solve the metadata issue, but there is one more
>> issue, the instances do not seem to get IP address and also it is not so
>> clear weather to use L2 with L3.
>> Regards,
>> Pranav
>>
>>
>> On Tue, Mar 19, 2013 at 1:18 AM, Anne Gentle <anne@xxxxxxxxxxxxx> wrote:
>>
>>> Hi all,
>>>
>>> I've got a doc bug against the Basic Install guide that I've been trying
>>> to understand. [1]
>>>
>>> The first issue is that the Basic Install guide doesn't tell the user to
>>> install the nova-api-metadata service. But there's more to it than just
>>> that, I believe. Two doc comments have noted that there's a routing issue
>>> as well:
>>>
>>> "there seems to be a step left out of this guide on the controller setup
>>> ...once you create the tenant subnets you need to add the route from the
>>> internal ips in this case route add -n 10.5.5.0/24 gw (the external
>>> router project IP ) once i did this on the controller node it pulls the
>>> metadata perfectly"
>>>
>>> Does this routing sound like the solution in your cases?
>>>
>>> Anne
>>>
>>> 1. https://bugs.launchpad.net/openstack-manuals/+bug/1108040
>>>
>>>
>>> On Mon, Mar 18, 2013 at 2:11 PM, Pranav <pps.pranav@xxxxxxxxx> wrote:
>>>
>>>> Having similar issues... someone please do help us if poss.
>>>> Regards,
>>>> Pranav
>>>>
>>>>
>>>> On Tue, Mar 19, 2013 at 12:35 AM, Gui Maluf <guimalufb@xxxxxxxxx>wrote:
>>>>
>>>>>
>>>>> >>From what I understood, without the retrieval of the metadata from the
>>>>> >server, the keys are not downloaded to the VM, is this correct?
>>>>>
>>>>> Yes. This is correct.
>>>>>
>>>>> AFAIK in Essex, the metadata service was pointed out through iptables. So there was a rule that DNAT the metadata service to the CC machine.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I had this metadata problem too, but I couldn't find out a proper solution.
>>>>> My guess is that this problem is related to the Gateway/Router in Folsom+Quantum installation. Or maybe in the metadata_host in the nova.conf file.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I hope someone could clarify this things for us.
>>>>>
>>>>>
>>>>> regards.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 18, 2013 at 7:32 AM, Bruno Parreira <bsendas@xxxxxxxxx>wrote:
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> We have deployed OpenStack using the guide provided at the OpenStack
>>>>>> webpage:
>>>>>>
>>>>>> Host A : controller node
>>>>>>
>>>>>> Host B : network node
>>>>>>
>>>>>> Host C : compute node
>>>>>>
>>>>>>
>>>>>>
>>>>>> Everything went fine during the installation process, but when we try to
>>>>>> instantiate a VM, the logs show that the VMs are unable to connect to the
>>>>>> metadata service (169.254.169.254).
>>>>>>
>>>>>> We've tried this with the Ubuntu image and the Cirros image, but the result
>>>>>> is the same.
>>>>>>
>>>>>>
>>>>>>
>>>>>> >From what I understood, without the retrieval of the metadata from the
>>>>>> server, the keys are not downloaded to the VM, is this correct?
>>>>>>
>>>>>> Because we can ping the IP address assigned to the VM from the network node,
>>>>>> and if we assign a floating IP to the VM, the public IP also responds to
>>>>>> ping replys.
>>>>>>
>>>>>> But we are unable to ssh into the VMs, with the error: "Read from socket
>>>>>> failed: Connection reset by peer"
>>>>>>
>>>>>> If we try to telnet into the public IP this is the result:
>>>>>>
>>>>>>
>>>>>>
>>>>>> controller@controller:~$ telnet x.x.x.x 22
>>>>>>
>>>>>> Trying x.x.x.x...
>>>>>>
>>>>>> Connected to x.x.x.x.
>>>>>>
>>>>>> Escape character is '^]'.
>>>>>>
>>>>>> SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Protocol mismatch.
>>>>>>
>>>>>> Connection closed by foreign host.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> In which node is the metadata service supposed to be running (compute,
>>>>>> network or controller)?
>>>>>>
>>>>>> Should the IP address 169.254.169.254 be reachable outside the VM?
>>>>>>
>>>>>> Is there an alternative to the metadata service?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Bruno Parreira
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~openstack
>>>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *guilherme* \n
>>>>> \t *maluf*
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~openstack
>>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~openstack
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>
References