[15:18] <minimal> it's been very quiet in here the past week or 2
[15:53] <meena> eery
[15:54] <falcojr> that must mean cloud-init is perfect and there's no more problems to discuss ;)
[15:58] <falcojr> minimal: to your earlier question, it's about whether you want to change an existing password vs set it for new user creation, though I agree it's confusing. Probably would have been better to have a separate field indicating whether to update the password for an existing user
[16:18] <meena> falcojr: do we not do… idempotency?
[16:20] <falcojr> no
[16:24] <minimal> falcojr: I don't really see the point of making a distinction between the 2 actions
[16:26] <falcojr> I think it'd be fairly relevant when making golden images. You don't want to change the password for a pre-existing user that has already changed their password to something else
[16:28] <minimal> but you can provide "sudo" or "ssh_authorized_keys" etc to change those attributes of a pre-existing user...
[16:28] <minimal> so it is a bit inconsistent
[16:28] <minimal> and you can use "lock_passwd" for a pre-existing user which *will* change their password by prefixing it with "!" in /etc/shadow
[20:03] <blackboxsw> > "it's been very quiet in here the past week or 2"   :) not at all unrelated to final freeze testing, validation of upstream cloud-init in upcoming release of Ubuntu mantic https://discourse.ubuntu.com/t/mantic-minotaur-release-schedule/34989  late Apr and late Oct tend to get a stream of QA and verification checks for cloud-init on different platforms that are not specifically covered in our unittests or integration tests
[20:04] <blackboxsw> and yep, "no [upstream] problems to discuss" so far.