[13:42] <nanoceli> Hello, recently I knew cloud-init, if somebody here can give me help with a funcionality? I have a VM running in azure, and inside it I am running a server en local host in diferentes ports, I need expose the local host to a external browser, can i use cloud init for that?
[15:07] <akutz> blackboxsw / falcojr: Pengpeng from the GuestOS team just notified me that the new VMware DS is not selected by default on Bionic, Focal, and Hirsute. They mentioned you have to run dpkg-reconfigure (much like I did when I upgraded from Focal to cloud-init 21.3 in my testing). I indicated this may simply be because 21.3 is not yet built into those images, but I do not know if that is the case. Is this behavior still expected? Thanks!
[15:11] <falcojr> akutz: if they're upgrading an existing instance to proposed and not running `cloud-init clean` (not that they necessarily should) after upgrade, then yes, this would be expected
[15:11] <akutz> I did not think cloud-init clean would automatically add the VMware DS (or any DS) to the list?
[15:13] <falcojr> nanoceli: there are no specific modules that I'm aware of that would make that easier, but you could use the runcmd module https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd or just pass a shell script as user data if nothing else you're doing requires a cloud config
[15:14] <falcojr> akutz: right, my bad
[15:26] <akutz> No worries.
[16:42] <akutz> falcojr: FWIW, because I searched for the previous conversation about upgrades and dpkg-reconfigure for my colleagues anyway, I will also post that link here for others wanting additional context - https://irclogs.ubuntu.com/2021/08/18/%23cloud-init.html
[16:47] <Guest42> how do I luks encrypt during install?
[19:46] <blackboxsw> falcojr: https://github.com/canonical/pycloudlib/pull/161/files +1'd for your SRU test improvemenst. If you want to keep adding to it  as you go through SRU verification feel free.
[19:46] <ubottu> Pull 161 in canonical/pycloudlib "Sru issues" [Open]
[21:51] <blackboxsw> hrm smoser per https://github.com/canonical/cloud-init/pull/827 we merged Vultr Datasource which has an interesting vendordata format that doesn't really seem to align with typical patterns for vendordata overriding cfg on disk. There is a followup Vultr PR up for review where I'm sort of wondering whether we want to continue to let this datasource  drive in a custom vendordata format route.
[21:51] <ubottu> Pull 827 in canonical/cloud-init "Add Vultr support" [Merged]
[21:51] <blackboxsw> if you or falcojr or rharper get a chance to peek at the following https://github.com/canonical/cloud-init/pull/987/files#r698832379 and have opinions one way or another I'm game for discussion.
[21:51] <ubottu> Pull 987 in canonical/cloud-init "Cleanup Vultr support" [Open]
[21:51] <blackboxsw> maybe I'm misreading the datasource
[22:14] <rharper> blackboxsw: I've not followed along very well with vultr ; it appears that vendor-data is a collection of DataSource specific config, that is _not_ actual cloud-config;  AFAICT, each one of those should really be in just the plain meta-data;    vendor-data IIUC, has historically been  *valid* user-data but supplied by the vendor as "default" values for certain user-data options. 
[22:31] <blackboxsw> Thanks rharper; that's kindof what I thought. It looks like Vultr added the datasource with vendordata that **isn't valid user-data**. So it has a smell of something not quite right, or something that doesn't align with how we process vendordata on all other datasources (given our merge logic in cloudinit.stages).
[22:34] <blackboxsw> the thing that's strange is that the original implemetation appended some cloud-config to the data https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceVultr.py#L86-L88  which looks to be a list of cmds to execute on CLI (via ethtool etc for user_scripts) and a supplemental #cloud-config user-data section as vendordata_raw.
[22:35] <blackboxsw> so without their `cloud-init query merged_cfg` or `cloud-init query vendordata` I can't really understand how it's being interpreted by cloud-init
[22:35] <blackboxsw> anyhow they've been responsive, so will let that conversation play out
[22:39] <rharper> it's hard to say without seeing the scripts, but it *sounds* like they're sending an array of scripts, which may include #cloud-config snippets, and then when _process_vendordata() runs it'll run through each one; 
[22:40] <rharper> which isn't too far off from say vendordata being a large multi-part mime payload 
[22:41] <rharper> I don't know how much control the datasource needs to have; if they just send multipart mime as vendor-data, then the datasource doesn't need to do anything at all , right ? 
[22:48] <rharper> they could be using sources.convert_vendordata() like OpenStack does; and post multi-part mime scripts as vendor-data