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.
