openstack team mailing list archive

[Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx>]

The Ubuntu requires metadata, since there is no password there...
The CirrOS have a pre-configured password "cubswin:)", so, it can be used
without metadata...

Best,
Thiago


On 23 April 2013 15:32, Paras pradhan <pradhanparas@xxxxxxxxx> wrote:

> Does these require metadata?
>
>
> http://uec-images.ubuntu.com/releases/12.04/release/ubuntu-12.04-server-cloudimg-amd64-disk1.img
>
> http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-disk.img
>
> Thanks,
> Paras.
>
>
> On Tue, Apr 23, 2013 at 12:53 PM, Martinx - ジェームズ <
> thiagocmartinsc@xxxxxxxxx> wrote:
>
>> Hi!
>>
>> I just delete my subnet, to create it again without specifying `--gateway
>> 10.33.14.1', my pre-installed images still works but, cloud based images,
>> that requires metadata, doesn't.
>>
>> I'm running out of options again...
>>
>> I tried with and without those options:
>>
>> ---
>> enable_isolated_metadata = True
>> enable_metadata_network = True
>>
>> `--gateway 10.33.14.1' on quantum subnet-create...
>> ---
>>
>> ...multiple times, doesn't work.
>>
>> Tks,
>> Thiago
>>
>>
>> On 23 April 2013 13:19, Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx>wrote:
>>
>>> Thank you Orlando!
>>>
>>> I just remove `quantum-l3-agent' for the sake of simplicity (I don't
>>> want it for now) and have enabled `enable_isolated_metadata = True' in
>>> dhcp_agent.ini but, same result. Metadata doesn't work.
>>>
>>> The CirrOS doesn't reach the metadata server. Also, within CirrOS, there
>>> is no route to 169.254.0.0/16 network. Probably because its dhcp client
>>> isn't ready with option 121 ???
>>>
>>>
>>> Also, the `Ubuntu Cloud Image' doesn't reach the metadata too, I'm
>>> seeing:
>>>
>>>
>>> "20130423 15:13:05,687  util.py[WARNING]: '
>>> http://169.254.169.254/20090404/metadata/instanceid' failed [49/120s]:
>>> url error [timed out]"
>>>
>>>
>>> And, I have a `Pre-Installed' Ubuntu template that I can boot and login,
>>> it have the option 121 configured but, no route to 169.254.0.0/24network in my routing tables.
>>>
>>> To try one more option, I just enable the `enable_metadata_network =
>>> True' but, doesn't work either.
>>>
>>> Anyway, this isn't off-topic, because of enabling metadata without L3 on
>>> a Single Flat, is on my TODO list to improve my document, the "Ultimate
>>> OpenStack Grizzly Guide", so, it is right on topic.
>>>
>>>
>>> And I really appreciate your help! Now I have a much better direction to
>>> follow.
>>>
>>> But, I still can't figure out how to put metadata to work. Too
>>> complicated...
>>>
>>>
>>> One more question, at the dhcp_agent, there is a message:
>>>
>>> "The metadata service will only be activated when the subnet gateway_ip
>>> is None."
>>>
>>> What this means?
>>>
>>> It means that I can't use `--gateway 10.33.14.1' when running the
>>> `quantum subnet-create' ?
>>>
>>>
>>> Tks!
>>> Thiago
>>>
>>>
>>> On 23 April 2013 04:48, Salvatore Orlando <sorlando@xxxxxxxxxx> wrote:
>>>
>>>> Quantum's metadata solution for Grizzly can run either with or without
>>>> the l3 agent.
>>>> When running within the l3 agent, packets directed to 169.254.169.254
>>>> are sent to the default gateway; the l3 agent will spawn a metadata proxy
>>>> for each router; the metadata proxy forwards them to the metadata agent
>>>> using a datagram socket, and finally the agent reaches the Nova metadata
>>>> server.
>>>>
>>>> Without the l3 agent, the 'isolated' mode can be enabled for the
>>>> metadata access service. This is achieved by setting the flag
>>>> enable_isolated_metadata_proxy to True in the dhcp_agent configuration
>>>> file. When the isolated proxy is enabled, the dhcp agent will send an
>>>> additional static route to each VM. This static route will have the dhcp
>>>> agent as next hop and 169.254.0.0/16 as destination CIDR; the dhcp
>>>> agent will spawn a metadata proxy for each network. Once the packet reaches
>>>> the proxy, the procedure works as above. This should also explain why the
>>>> metadata agent does not depend on the l3 agent.
>>>>
>>>> If you are deploying the l3 agent, but do not want to deploy the
>>>> metadata agent on the same host, the 'metadata access network' can be
>>>> considered. This option is enabled by setting enable_metadata_network on
>>>> the dhcp agent configuration file. When enabled, quantum networks whose
>>>> cidr is included in 169.254.0.0/16 will be regarded as 'metadata
>>>> networks', and will spawn a metadata proxy. The user can then connect such
>>>> network to any logical router through the quantum API; thus granting
>>>> metadata access to all the networks connected to such router.
>>>>
>>>> I think the documentation for quantum metadata has not yet been merged
>>>> in the admin guide.
>>>> I hope this clarifies the matter a little... although this thread has
>>>> gone a little bit off-topic. Can you consider submitting one or more
>>>> questions to ask.openstack.org?
>>>>
>>>>
>>>> Regards,
>>>> Salvatore
>>>>
>>>>
>>>> On 23 April 2013 00:50, Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx>wrote:
>>>>
>>>>> That is precisely what I'm trying to figure out!
>>>>>
>>>>> How to setup metadata without L3 using Quantum Single Flat. I can't
>>>>> find any document about this.
>>>>>
>>>>> Plus, to make things worse, the package quantum-metadata-agent *DOES
>>>>> NOT DEPENDS* on quantum-l3-agent.
>>>>>
>>>>> BTW, I'm sure that with my guide, I'll be able to run Quantum on its
>>>>> simplest scenario!
>>>>>
>>>>> Give it a shot!!
>>>>> https://gist.github.com/tmartinx/d36536b7b62a48f859c2
>>>>>
>>>>> My guide is perfect, have no bugs. Tested it +50 times.
>>>>>
>>>>> Cheers!
>>>>> Thiago
>>>>>
>>>>>
>>>>>
>>>>> On 22 April 2013 19:18, Paras pradhan <pradhanparas@xxxxxxxxx> wrote:
>>>>>
>>>>>> So this is what I understand. Even if you do flat (nova-network
>>>>>> style) , no floating ip you still need l3 for metadata(?). I am really
>>>>>> confused. I could never ever make quantum work. never had any issues with
>>>>>> nova-network.
>>>>>>
>>>>>> Paras.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 19, 2013 at 8:35 PM, Daniels Cai <danxcai@xxxxxxxxx>wrote:
>>>>>>
>>>>>>> paras
>>>>>>>
>>>>>>> In my experience the answer is yes .
>>>>>>> In grizzly , metadata proxy works in the qrouter's name space ,no
>>>>>>> router means no metadata .
>>>>>>> I am not sure whether any other approaches .
>>>>>>>
>>>>>>> Daniels Cai
>>>>>>>
>>>>>>> http://dnscai.com
>>>>>>>
>>>>>>> 在 2013-4-20，9:28，"Martinx - ジェームズ" <thiagocmartinsc@xxxxxxxxx> 写道：
>>>>>>>
>>>>>>> Daniels,
>>>>>>>
>>>>>>> There is no `Quantum L3' on this setup (at least not on my own
>>>>>>> environment / guide).
>>>>>>>
>>>>>>> So, this leads me to one question: Metadata depends on L3?
>>>>>>>
>>>>>>> I do not want Quantum L3 package and I want Metadata... Is that
>>>>>>> possible?
>>>>>>>
>>>>>>> Tks,
>>>>>>> Thiago
>>>>>>>
>>>>>>>
>>>>>>> On 19 April 2013 21:44, Daniels Cai <danxcai@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hi Paras
>>>>>>>> The log says your dhcp works fine while metadata is not
>>>>>>>> Check the following steps
>>>>>>>>
>>>>>>>> 1.Make sure nova API enables metadata service
>>>>>>>>
>>>>>>>> 2. A virtual router should be created for your subnet and this
>>>>>>>> router is binding with a l3 agent
>>>>>>>>
>>>>>>>> 3.in the l3 agent metadata proxy service should be works fine
>>>>>>>> Metadata service config file should contains nova API host and
>>>>>>>> keystone auth info
>>>>>>>>
>>>>>>>> 4.  Ovs bridge br-ex is needed in your l3 agent server even you
>>>>>>>> don't need floating ip
>>>>>>>>
>>>>>>>> Daniels Cai
>>>>>>>>
>>>>>>>> http://dnscai.com
>>>>>>>>
>>>>>>>> 在 2013-4-19，23:42，Paras pradhan <pradhanparas@xxxxxxxxx> 写道：
>>>>>>>>
>>>>>>>> Any idea why I could not hit
>>>>>>>> http://169.254.169.254/20090404/instanceid ? Here is what I am
>>>>>>>> seeing in cirros .
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sending discover...
>>>>>>>> Sending select for 192.168.122.98...
>>>>>>>> Lease of 192.168.122.98 obtained, lease time 120
>>>>>>>> deleting routers
>>>>>>>> route: SIOCDELRT: No such process
>>>>>>>> route: SIOCADDRT: No such process
>>>>>>>> adding dns 192.168.122.1
>>>>>>>> adding dns 8.8.8.8
>>>>>>>> cirrosds 'net' up at 4.62
>>>>>>>> checking http://169.254.169.254/20090404/instanceid
>>>>>>>> failed 1/20: up 4.79. request failed
>>>>>>>> failed 2/20: up 6.97. request failed
>>>>>>>> failed 3/20: up 9.03. request failed
>>>>>>>> failed 4/20: up 11.08. request fa
>>>>>>>>
>>>>>>>> ..
>>>>>>>> --
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Paras.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 11, 2013 at 7:22 AM, Martinx - ジェームズ <
>>>>>>>> thiagocmartinsc@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Guys!
>>>>>>>>>
>>>>>>>>>  I just update the *Ultimate OpenStack Grizzly Guide*<https://gist.github.com/tmartinx/d36536b7b62a48f859c2>
>>>>>>>>> !
>>>>>>>>>
>>>>>>>>>  You guys will note that this environment works with "*echo 0 >
>>>>>>>>> /proc/sys/net/ipv4/ip_forward*", on *both* controller *AND*compute nodes! Take a look! I didn't touch the /etc/sysctl.conf file and it
>>>>>>>>> is working!
>>>>>>>>>
>>>>>>>>>  I'll ask for the help of this community to finish my guide.
>>>>>>>>>
>>>>>>>>>  On my `TODO list' I have: enable Metadata, Spice and Ceilometer.
>>>>>>>>> Volunteers?!
>>>>>>>>>
>>>>>>>>> Best!
>>>>>>>>> Thiago
>>>>>>>>>
>>>>>>>>> On 20 March 2013 19:51, Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Hi!
>>>>>>>>>>
>>>>>>>>>>  I'm working with Grizzly G3+RC1 on top of Ubuntu 12.04.2 and
>>>>>>>>>> here is the guide I wrote:
>>>>>>>>>>
>>>>>>>>>>  Ultimate OpenStack Grizzly Guide<https://gist.github.com/tmartinx/d36536b7b62a48f859c2>
>>>>>>>>>>
>>>>>>>>>>  It covers:
>>>>>>>>>>
>>>>>>>>>>  * Ubuntu 12.04.2
>>>>>>>>>>  * Basic Ubuntu setup
>>>>>>>>>>  * KVM
>>>>>>>>>>  * OpenvSwitch
>>>>>>>>>>  * Name Resolution for OpenStack components;
>>>>>>>>>>  * LVM for Instances
>>>>>>>>>>  * Keystone
>>>>>>>>>>  * Glance
>>>>>>>>>>  * Quantum - Single Flat, Super Green!!
>>>>>>>>>>  * Nova
>>>>>>>>>>  * Cinder / tgt
>>>>>>>>>>  * Dashboard
>>>>>>>>>>
>>>>>>>>>>  It is still a draft but, every time I deploy Ubuntu and Grizzly,
>>>>>>>>>> I follow this little guide...
>>>>>>>>>>
>>>>>>>>>>  I would like some help to improve this guide... If I'm doing
>>>>>>>>>> something wrong, tell me! Please!
>>>>>>>>>>
>>>>>>>>>>  Probably I'm doing something wrong, I don't know yet, but I'm
>>>>>>>>>> seeing some errors on the logs, already reported here on this list. Like
>>>>>>>>>> for example: nova-novncproxy conflicts with novnc (no VNC console for now),
>>>>>>>>>> dhcp-agent.log / auth.log points to some problems with `sudo' or the
>>>>>>>>>> `rootwarp' subsystem when dealing with metadata (so it isn't working)...
>>>>>>>>>>
>>>>>>>>>>  But in general, it works great!!
>>>>>>>>>>
>>>>>>>>>> Best!
>>>>>>>>>> Thiago
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>