[00:05] <minimal> falcojr: noticed that growpart/RPI/LUKS issues. A couple of things, in the launchpad bug you said "That can only happen once the encrypted partition has been unlocked", as its a RPI (where boot is a separate non-encrypted partition/fs) and he mentioned its the root encryption (holding rootfs) that's encrypted then by the time that cloud-init runs to run growpart then the rootpart would obviously be unlocked that that stage.
[00:07] <minimal> falcojr: the other point is that he said he used cryptsetup with "-sector-size 4096". The cryptsetup manpage says that's only available for LUKSv2 and says that the sector size should not be large than the underlying device's sector size, so unless he's using a 4K device (I'd assume a 4K/4K devices rather than a 512/4K device even) then using "--sector-size 4096" is risky
[00:10] <minimal> falcojr: I've been meaning to test growpart with LUKS partitions, I just haven't gotten around to it so far but I'll try and find some time to test it and see what happens (none of this is RPI-specific, I've got scripts to create Adiantum-based LUKS rootfs VMs (with cloud-init) disk images
=== esv_ is now known as esv
=== janitha72 is now known as janitha7
=== janitha78 is now known as janitha7
[07:02] <meena> on (Open)BSD we could replace sudo with doas…
[13:51] <meena> mounts module claims it works on all distros, but config.tmpl disables it on BSD
[13:56] <meena> https://bugs.launchpad.net/cloud-init/+bug/1992798
[13:56] -ubottu:#cloud-init- Launchpad bug 1992798 in cloud-init "cc_mounts: module claims it works on all distros, but config disables it on BSD" [Undecided, New]
[13:59] <minimal> meena: perhaps it just hasn't been tested by anyone on BSD?
[14:00] <meena> minimal: makes sense
[14:01] <minimal> meena: not sure if /etc/fstab fields are exactly the same between Linux and BSD
[14:02] <meena> https://www.freebsd.org/cgi/man.cgi?fstab(5)#EXAMPLES
[14:03] <meena> minimal: looks the same as on my Linux box
[14:10] <minimal> try it and see, its the best way to know :-)
[14:17] <meena> minimal: it's on my todo list
=== janitha74 is now known as janitha7
=== janitha79 is now known as janitha7
[20:47] <hadmut> Hi, question about cloud-init on LXD: I want to provide both user-data and vendor-data, but the vendor-data is not executed if user-data is present, only if absent. Why that? Shouldn't they be executed both? 
[20:48] <falcojr> hadmut if both define the same keys, user data will ovewrite vendor data. Would that be relevant in your case?
[20:48] <blackboxsw> https://cloudinit.readthedocs.io/en/latest/topics/vendordata.html?#vendor-data mentions the intent and reasoning there for merge priority
[20:48] <hadmut> Both do correctly arrive in /var/lib/cloud/instances/UUID/cloud-config.txt and vendor-cloud-config.txt
[20:49] <hadmut> Currently just testing, each containing just a runcmd – touch somefilename 
[20:50] <hadmut> So vendor cannot execute a command if user executes any other command?
[20:52] <meena> holman: re https://github.com/canonical/cloud-init/pull/1783 why are you reverting the sys.executable change here: https://github.com/canonical/cloud-init/pull/1778 ?
[20:52] -ubottu:#cloud-init- Pull 1783 in canonical/cloud-init "Do not override existing value for PYTHON and do not hardocde the binary in unittest target" [Open]
[20:52] -ubottu:#cloud-init- Pull 1778 in canonical/cloud-init "Ansible Control Module" [Open]
[20:52] <waldi> hadmut: so "if both define the same keys" is true
[20:55] <hadmut> waldi does this make any sense if any command executed by the user cancels all commands given by the vendor?
[20:55] <waldi> hadmut: and your case is even described in the document blackboxsw gave you
[20:55] <holman> meena: that was unintentional, fixed
[20:56] <hadmut> waldi blackboxsw not really. I've read that before, and it stresses that the user *can* disable the vendor, if he wants, but not, that his data enforces cancelling. 
[20:57] <blackboxsw> hadmut: right. any user can override anything vendors perfer by providing same config keys in their own user-data or going so far as providing the following to turn off any vendor_data
[20:57] <blackboxsw> #cloud-config
[20:57] <blackboxsw> vendor_data:
[20:57] <blackboxsw>   enabled: false
[20:58] <falcojr> hadmut: https://i.imgur.com/Wh4wyAa.png
[20:59] <falcojr> also, if you're looking to just run a script, I'm pretty sure you can just pass a script for vendor data, rather than cloud-config
[20:59] <blackboxsw> and vendor scripts themselves can be put into custom images in /var/lib/cloud/scripts/vendor if desired which won't get overwritten https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-vendor
[21:00] <meena> holman: good, good https://youtu.be/01-e3-6CVn0
[21:04] <hadmut> I have not yet figured out where this scripts/vendor directory is on LXD. The docs just say "On select Datasources"...
[21:05] <hadmut> Are you just experienced users, or are you developers/product owners?
[21:06] <blackboxsw> good pt falcojr on passing a script as vendor_data. If cloud-init recognized the #! it would just run that and it won't be overridden by typical #cloud-config userdata https://paste.opendev.org/show/bUv7BmkZ5VDpcYCpvtRm/   hadmut 
[21:07] <blackboxsw> the paste above shows how to quicky set both vendor-data and user-data and have them both active w/out collision
[21:08] <blackboxsw> per "I have not yet figured out where this scripts/vendor directory is on LXD" sorry that's a doc problem, I'll fix that now hadmut. `/var/lib/cloud/sciprts/vendor` on any dataousrce
[21:08] <blackboxsw> *datasource
[21:08] <falcojr> blackboxsw: surprised that worked tbh...you have no #! in your vendor data
[21:09] <hadmut> So how would I put a script in there if write_files: doesn't work either?
[21:10] <blackboxsw>  falcojr hadmut sorry paste fail. re-paste of the above https://paste.opendev.org/show/bUFTdWpF69iL5c3fcr5O/
[21:10] <blackboxsw> I have a leading shebang there
[21:10] <meena> falcojr: to test the change you suggested for cc_ntp, i opened: https://bugs.launchpad.net/cloud-init/+bug/1992853
[21:10] -ubottu:#cloud-init- Launchpad bug 1992853 in cloud-init "add sysvinit config for OpenBSD" [Undecided, New]
[21:12] <falcojr> makes sense
[21:12] <blackboxsw> hadmut: falcojr.holman and I are upstream developers for cloud-init, meena/minimal are  two super active contributors from BSD and Alpine respoectively. waldi, thanks for helping here too!
[21:13] <hadmut> So you need to run a shebang shell script to workaround a design that doesn't work itself?
[21:13] <meena> for a project sponsored by the FreeBSD Foundation, I'm doing way too much work for OpenBSD…
[21:14] <hadmut> Why do the docs then claim that vendor-data just works as user-data, if such workarounds are needed?
[21:14] <blackboxsw> hadmut: the design works as intended.   base configuration comes from the filesystem comes first in terms of merge priority the default config metadata from a cloud can supplement/override that config, then vendor data, then user-data
[21:15] <falcojr> hadmut: "user supplied cloud-config is merged over cloud-config from vendordata." is on the vendor data page
[21:15] <blackboxsw> because priority of final configuration should be in the hands ultimately of the user to squelch or silence any vendordata or base config they don't want.
[21:16] <blackboxsw> back in a few folks. short conference
[21:18] <meena> also: merging scripts sounds pretty dangerous to me
[21:19] <hadmut> Sorry to say that, no offense, but a broken design never ever got better by mentioning in the docs that it is broken. 
[21:19] <sam_> minimal: sorry, been busy last few days, if I have tried openrc+gentoo, it was a while ago, I can ask around though
[21:20] <meena> sam_: would be cool if you could also get a feel for how common it is.
[21:21] <minimal> sam_: no problem, I'm still intending to submit openrc tweaks for Alpine in alpine.py but perhaps they later be made more generic to also cover Gentoo
[21:22] <minimal> hadmut: as blackboxsw indicated it is working as intended so it is not broken
[21:23] <meena> it might be unintuitive, but that's a different issue
[21:24] <hadmut> minimal: working as intended is not enough for not beeing broken, especially if broken by design. Everything broken by design is as intended. The problem is that this leads to unpredictable results because you never know when a user (who usually doesnt see vendor data) accidently overrides a some configuration details. Sorry, but that is terrible. 
[21:24] <meena> if you think about it for a while tho, you will realize that it makes no sense: vendor-data is often opaque to users, so there could be destructive interactions
[21:26] <hadmut> meena: Exactly, that's the problem. And if that was intended, this is broken by design. 
[21:28] <minimal> hadmut: I don't want to start an argument, you believe it is broken by design, others may not believe that
[21:29] <hadmut> minimal: for every broken design, there is someone not believing it's broken, e.g. those who broke it.
[21:30] <meena> hadmut: that's enough now. we get it.
[21:30] <hadmut> Thank you. Bye.
[21:31] <meena> people should not use system configuration / provisioning software in anger.
[22:16] <blackboxsw> -> back school parent/teacher conference achieved.
[22:16] <minimal> blackbox: drama missed lol
[22:17] <blackboxsw> thx folks for continuing the conversation minimal & meena. :)
[22:19] <blackboxsw>  In the meantime, sounds like a feature would be to allow the broader visibility to vendordata (which can be seen from a user's point of view with cloud-init query vendordata)  or possibly the ability to  allow a datasource or base config to scope #cloud-config vendor-data as something treated distinctly that wouldn't collide or merge w/ user-data #cloud-config
[22:20] <blackboxsw> that represents in a change in behavior from how this was vendor-data was treated in the past, but we still have the user-data switch to "vendor_data:\n enable: false" that could provide users the say as to whether or not they trust vendor_data for their particular deployment needs.
[22:24] <blackboxsw> " The problem is that this leads to unpredictable results because you never know when a user (who usually doesnt see vendor data) accidently overrides a some configuration details...." valid feature request. We could easily make this more conspicuous by logging warnings when we see user-data #cloud-config keys that override vendor-data. So that'd raise awareness for users unaware of such overrides. 
[22:26] <blackboxsw> but. we should ultimately allow users to retain control to be able to override vendor-data or disable it completely if unwanted. What we have at the moment is granularity for overrides in any vendor_data key due to our merge order prioritization. Maybe they want some of vendor_data to apply, but not others for certain use-cases.  `vendor_data: enable:(true|false)` only gives the user a hammer to ignore  all vendor_data.
[22:27] <blackboxsw> this would need more thought to spec out implications. but, yeah maybe hadmut will return and help participate in developing that use-case more :)