On 2012-06-07 23:52, Kapil Thangavelu wrote:
so our hypothesis atm is that maas isn't returning a populated userdata to the machine on its first boot, and that's basically returning a 200 http status response with empty content. if a user subsequently reboots the machine the correct metadata is in place but cloud-init won't run the nesc parts again as they were already run on first boot, this includes putting keys into place and running user scripts which juju needs to initialize the machine. Apparently destroy-environment followed by bootstrap works because the correct metadata is returned subsequently. so it sounds like a timing issue getting the metadata to the machine's 'first' first boot with a new disk image. i wonder if in truth its the old metadata for the instance that's being returned though on the subsequent bootstrap, since its identical content and node uuids are stable for the machine across re-imaging.
It may help that the current trunk, in demo or development configurations, lets you access the metadata for any given node.
Where the node would access http://<host>/<path>/metadata/latest/ to get its own metadata, you can see the same data at http://<host>/<path>/metadata/latest/by-mac/<mac>/
(Where <mac>, you guessed it, is the node's MAC address). Jeroen -- Mailing list: https://launchpad.net/~maas-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~maas-devel More help : https://help.launchpad.net/ListHelp
