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/24 network 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 <[email protected]> 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 - ジェームズ <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 - ジェームズ" <[email protected]> 写道： >>>> >>>> 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 <[email protected]> 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 <[email protected]> 写道： >>>>> >>>>> 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 - ジェームズ < >>>>> [email protected]> 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 - ジェームズ <[email protected]>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 : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~openstack >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
