[09:48] <plundra> Is it fine (without side effects) to reboot in runcmd? Or is there a cleaner way to reboot after all once-per-instance stuff is done?
[09:50] <plundra> eh, the power_state module of course :-) Pardon me.
[09:54] <plundra> The timeout docs say "Time in seconds to wait for the cloud-init process to finish" - Finish what? Would this need to be large enough to include *all other* things being done in cloud-init? Like my runcmd stuff etc?
[12:05] <aciba> plundra: yes, exactly. It is explained here: https://cloudinit.readthedocs.io/en/latest/reference/modules.html#power-state-change
[12:15] <plundra> aciba: That's where I quoted it from, under config schema; I don't get it still, what is the timeout for?
[12:19] <aciba> It is explained in the last paragraph. delay is the time that will be attached to the shutdown/reboot cmd and timeout is the time cc_power_state_chage will wait to issue the command.
[12:19] <aciba> last paragraph of the summary.
[12:22] <plundra> I really don't parse it... Delay is *after* cloud-init has finished and now (none) default - okay great, but what is the correlation with timeout?
[12:23] <plundra> Like I quoted first "time in seconds to wait for the cloud-init process to finish" <- So this is a global timeout for all of the cloud-init? 
[12:24] <plundra> I have packages_{update,upgrade} to true for example, and if it that takes longer than the default 30s timeout, power_state set to mode: reboot would still just reboot the machine mid-upgrade? If it is too slow?
[12:24] <plundra> Or a 'runcmd' with `sleep 35 && dostuff` would never dostuff?
[12:44] <aciba> power-state-change is typically sorted the last in the cloud-final stage, and then package-update-upgrade-install is executed synchronously before power-stage-change is executed
[12:45] <aciba> I think the timeout is to let side-effects trigger by previous modules finish, or let subsequent modules finish
[12:47] <aciba> `cloud-init query merged_cfg.cloud_final_modules` to check how power-state-change is sorted
[12:48] <plundra> Ok, that makes sense. But if modules and runcmds are all synchronous without spawning things in the background, and default order of power-state last, timeout is irrelevant? 
[12:48] <plundra> Yeah it is last there. 
[12:49] <aciba> I think that piece of documentation could be improved, as we can see it is difficult to parse. would you, plundra mind creating an issue reflecting that?
[12:50] <aciba> there could be other things running as a side effect of some cloud-init config module I guess
[12:51] <plundra> Wouldn't that be considered a bug in that case? If you rely on things after being slow, and/or the "catch all" 30 seconds timeout? :)
[12:52] <plundra> I'll try and formulate a [docs]-issue later, absolutely. Thanks for the help!
[13:48] <minimal> plundra: the value of delay is what is passed to the shutdown command
[13:50] <minimal> "timeout" is the maximum time that will be waited for cloud-init to finish (from when the cc_power_state_module runs) before activating the poweroff/reboot/halt activity
[13:51] <minimal> however the value of "condition" is also taken into account
[14:30] <nbathum> anyone know if it is allowed to use the cloud-init logo in a presentation?
[16:19] <blackboxsw> nbathum: can you restate the question? If someone is presenting about cloud-init and cloud-init is involved/metnioned in that function/feature/product I think using that logo is reasonable in a presentation.
[18:34] <nbathum> I'll be presenting about using cloud-init together with NixOS. the cloud-init system is used for a generic "activation" phase to hook into pre-defined escape hatches out of the rigid NixOS module system
[18:35] <holmanb> nbathum: presenting where? will the presentation be available online?
[18:35] <blackboxsw> fun nbathum, please do reflect that presentation content at some point back here so we can celebrate your efforts.  & learn about different use-cases.
[18:36] <nbathum> holmanb: at NixCon, September 8-9th. not sure of the exact time yet, the schedule is not finalized. it should be streamed online live
[18:37] <blackboxsw> we also sometimes promote external presentation material @ https://cloudinit.readthedocs.io/en/latest/reference/faq.html#where-can-i-learn-more (though we should probably better organize that content in another place besides FAQ)
[18:37] <nbathum> blackboxsw: will do!
[18:38] <nbathum> talk link is here if you're interested. https://talks.nixcon.org/nixcon-2023/talk/review/7ZTGHY9THVQEDNACLPA8QRSPZMZS8RGD
[18:54] <holmanb> nbathum: +1 thanks
[22:34] <holmanb> blackboxsw: not the prettiest solution, but the alternative would force including more dependencies just to bootstrap and the use case is well defined by the user, so for now proposing this https://github.com/canonical/cloud-init/pull/4380
[22:34] -ubottu:#cloud-init- Pull 4380 in canonical/cloud-init "Fix pip-managed ansible" [Open]
[22:35] <holmanb> blackboxsw: also I closed and linked #4356 since it was a duplicate of #4244