[18:38] <ys__> Hi I am trying to use cloudinit to reset password, but not sure if it is doable.
[18:39] <ys__> My idea is running a user script on every boot to query a url. If the response is True, then rm sem/config-set_passwords file. After reboot vm, the password will be reset to original password
[18:40] <ys__> wondering will it work?
[19:27] <rharper> ys__: if you're going to query a URL to determine if you want to reset a passwd;  you might avoid using the cloud-config entirely and just have your script run; and modify the passwd  itself
[19:44] <ys__> rharper: yes you are right, it might be cleaner if just use a script to reset the password after URL query
[19:50] <ys__> rharper: BTW, I saw a file cloud-config.txt in /var/lib/cloud, is it retrieved from metadata service endpoint (169.254.169.254) ?
[19:52] <ys__> I tried to rm this file along with user-data.txt and user-data.txt.i in the same dir, then reboot the vm, cloudinit will re-created those files again. Is it retrieved from 169.254.169.254 this time? or it was cached somewhere?
[19:53] <rharper> it's the combined cloud-config that was sent to the instance from the datasource used;   depending on the cloud (and datasource) it may come from a metadata service url (like the one you see)
[19:53] <ys__> the reason i ask is because after I create the vm, I manually updated userdata in openstack and curl 169.254.169.254 reflected the update.
[19:54] <ys__> Then I removed those files, reboot the vm, however cloud init re-created those files with original user-data
[19:54] <rharper> different types of configuration is applied either once per instance, once per boot, or always, depending on the type
[19:54] <rharper> cloud-init does not (yet) dynamically watch metadata service and automatically reapply if the configuration has changed
[19:54] <ys__> ok
[19:55] <rharper> if you want to re-run cloud-init on the same instance with new user-data, you'll need to do somethign like:  rm -rf /var/lib/cloud/*  and reboot;  this wipes out the per-instance data, and cloud-init will run like firstboot
[19:56] <rharper> much of the data consumed is cached in /var/lib/cloud/instances/<instance-id>/*
[19:56] <ys__> yes i actually rm /var/lib/cloud/instances/<instance-id>/cloud-config.txt, user-data.txt and user-data.txt.i (any file with userdata)
[19:57] <ys__> but still re-created with original user-data (guess didn't query 169.254.169.254)
[19:57] <rharper> you'll need to remove anything under /var/lib/cloud/
[19:58] <rharper> if it finds the instance-id of an instance matches an existing directory in /var/lib/cloud/instances/ then it will assume it can use the cache and reloads it from the pickled object file
[19:59] <rharper> I've got to step out for a bit, but blackboxsw is still here and can help answer any more questions you might have
[19:59] <ys__> ok thanks
[19:59] <blackboxsw> +1
[20:02] <blackboxsw> yeah generally for clean reboot testing and validation we 'sudo rm -rf /var/log/cloud-init* /var/lib/cloud; sudo reboot' .. In this case, cloud-init will perform all initialization as if it were greenfield (unbooted) install and it will query your metadata service to pull all updated data
[20:03] <ys__> yeah, i didn't realize there is a pickled obj file...
[20:04] <ys__> i thought if cloudinit found some missing file, it will back to metadata service and retrieve the data. Now it make sense.
[20:04] <ys__> thanks!
[20:09]  * blackboxsw also wondered initially about also attempting something like 'sudo cloud-init single --name cc_users_groups --frequency always  since the user password was configured via userdata, but I *think* that might run into the caching problem too.
[20:15] <ys__> blackboxsw: will that reset user's password (to default) on every boot if frequency always?
[20:17] <blackboxsw> that'd be something that would have to be manually run each time I believe (it doesn't permanently designate frequency == always for the module). It just allows the module to look at the existing cache I thought and determine if the module was already run. I'll test now to confirm.
[20:56] <blackboxsw> ys__: validated that even  --frequency always hits the cache despite changed user-data. only fully proven approach is to rm -rf /var/lib/cloud in that case currently.
[21:00] <ys__> blackboxsw: Thanks. I guess best way i can do currently is to use a user script to query a url and rely on another script to reset password.
[21:00] <blackboxsw> I like the idea of ignoring the cache with some of these "cloud-init single --frequency always runs" I'll look at how tough that would be to implement
[21:01] <blackboxsw> but yeah probably rely on a script to reset password for the time being
[21:01] <ys__> ok thanks
[21:36] <blackboxsw> ok just integrated cloud-init analyze subcommand into cloudinit.cmd.main http://pastebin.ubuntu.com/25272516/
[21:37] <blackboxsw> took a  bit of restructuring on this today to allow an existing standalone tool (cloudinit-analyze)  to be called as a subcommand under cloud-init
[21:37] <blackboxsw> but it'll set a good precendent (once we review/agree) for pulling other tools into the fold