[01:46] <blackboxsw> FWIW, seems to "work fine"= on the cosmic azure instance I deployed. I could see the encoded content in the proper kvp_pool file
[14:19] <otubo> smoser: stupid question: that's my first time contributing on Launchpad (I'm from the mailing-list era). Shall I create a new branch a new pull-request? Or just push on top of that branch you already reviewed?
[14:20] <smoser> otubo: welcome to the cloud era ;)
[14:20] <smoser> you can push --force over whatever branch you have
[14:20] <smoser> launchpad will do the right thing
[14:21] <smoser> or you can 'git commit -a -m "add stuff smoser requested"'
[14:21] <smoser> and then git push (without --force)
[14:21] <smoser> generally i prefer the latter as it then is obvious what you've done to address that.
[14:21] <otubo> smoser: anything else after that? Like, create a new pull-request? Just push -f and we're good?
[14:49] <smoser> otubo: sorry, looked away. yeah, if you push over then launchpad upates the existing merge proposal
[19:16] <smoser> blackboxsw: in your jinja branch... should i be able to reference 'v1.cloud_name' ?
[19:16] <smoser> or is that not yet done.
[19:17] <blackboxsw> smoser: I think I found a bug in render, I'm trying to fix it now.
[19:17] <blackboxsw> rendered instance-data.json isn't being converted, I need to add a unit test for this
[19:17] <blackboxsw> smoser: and yes  you should be able to
[19:18] <blackboxsw> I was just testing it trying to draw up slides
[19:20] <blackboxsw> ohh I forgot to back out our persisting underscore values in initial instance-data.json and move it back into convert_jinja_instance_data
[19:21] <smoser> yeah, that seems to be it. if i changed my  instance_data to have underscores then it works.
[19:22] <blackboxsw> yeah, and I think we decided we didn't want to persist underscores in instance-data.json as snap relies on v1 keys that don't have underscores
[19:22] <smoser> yeah.
[19:22] <smoser> thats unfortunate though
[19:23] <blackboxsw> yeah costly to do that processing on each part render
[19:25] <blackboxsw> smoser: alternative: maybe at instance-data.json write time (in ds.get_data()) we could write the jinja processed content
[19:25] <blackboxsw> then we do it just once
[19:25] <blackboxsw> and souce that processed jinja_vars file when rendering jinja content?
[19:25] <blackboxsw> *source* rather
[19:27] <smoser> we can figure something out there.
[19:33] <blackboxsw> ok pushing a fix, but I need to sort a unit test failure still
=== apollo13_ is now known as apollo13
[20:49] <smoser> blackboxsw: for your consideration http://paste.ubuntu.com/p/QqGC8SdkgG/
[20:51] <blackboxsw> smoser: for your consideration https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/353530
[20:53] <blackboxsw> thanks smoser will play with that and pull it in.
[20:56] <smoser> blackboxsw: imds is https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service ?
[20:56] <smoser> shouldnt we have a version in our data then
[20:58] <blackboxsw> correct. smoser. after our discussion yesterday I started a branch to better represent the raw azure data (which has already landed)
[20:59] <blackboxsw> I'm not done w/ that branch yet to restucture instance-data.json on azure
[20:59]  * blackboxsw thinks it was yesterday, or maybe it was friday
[20:59] <smoser> :)
[21:00] <smoser> well, i hit a comment there. to that effect.
[21:00] <smoser> i have to run now.
[21:00] <blackboxsw> in any event, I think openstack and azure ds's both need a little tweak
[21:00] <blackboxsw> see you
[21:11] <smoser> blackboxsw: fyi, there is a 0821 cosmic build now \o/
[21:11] <blackboxsw> woot!
[21:11] <blackboxsw> getting easier
[21:11] <blackboxsw> each time
[21:11]  * smoser heads out.
[22:15] <socket-> Can anyone help me understand if/how cloudinit sets the hostname to ip-xxx-xxx-xxx-xxx? We want to change the default hostname as we spin up images to be 15 random hex characters instead of ip based.
[22:22] <blackboxsw> socket-: cloud-init generally gets hostname from the cloud's metadata service if present and applies it. For setting or generating hostname a user can specify a static hostname with a #cloud-config yaml file at instance creation time.
[22:23] <blackboxsw> https://pastebin.ubuntu.com/p/DZ43ptvtPT/
[22:23] <blackboxsw> example ^
[22:26] <socket-> blackboxsw: I'm not sure how familiar you are with AWS, but for example, we are using the ubuntu AMI (which I believe Ubuntu created) and it's default cloud init. Are you saying I would just modify the cloud-config to say something like hostname: $rand(15,[A-Z,a-z,0-9], save it as a new image, and each time someone launches one, they will get a random hostname?
[22:28] <socket-> looking at the default cloud.cfg, the only hostname option i see is "- set_hostname" under cloud_init_modules
[22:30] <blackboxsw> socket-: when the following branch is published you'll be able to specify something like the following:    https://pastebin.ubuntu.com/p/jcVvmgZSPh/
[22:31] <blackboxsw> socket-: correct, via aws CLI or web UI   you could currently a user-data file containing your "#cloud-config\nhostname: <random-value>"  statically generated content
[22:34] <blackboxsw> socket-: sorry branch in question is https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/335290 with some examples of rendering jinja templates.
[22:37] <blackboxsw> hrm. socket- I so you want a custom AMI that will by default set the hostname to a random string right... you aren't in control at the time the instance is created is that right?
[22:47] <blackboxsw> hrm, gotta bail for dinner
[23:02] <socket-> sorry man, got called away from my desk, yeah your right I want a custom ami that wukk set the hostname to a random string, and I am not in control of the time its created