=== vrubiolo1 is now known as vrubiolo
[11:19] <wCPO> Should the cloud-init package enable the relevant systemd services or should the user do it?
[12:04] <meena> wCPO: depends?
[12:12] <wCPO> meena: Okay? What is best practice?
[12:13] <wCPO> cloud-init-generator only enables the cloud-init.target, the services still needs to be enabled manually AFAIK
[12:14] <meena> what's cloud-init-generator?
[12:15] <wCPO> meena: https://github.com/canonical/cloud-init/blob/master/systemd/cloud-init-generator.tmpl
[13:34] <smoser> meena: the services are wanted by the target
[13:34] <smoser> so the generator just controls whether or not hte target is active
[13:35] <smoser> so wCPO , the answer to your question is:
[13:37] <smoser>  on systemd system, the package should place the generator (cloud-init-generator) in /lib/systemd/systemd-generators
[13:37] <smoser> and should install the systemd units and target as is.
[13:38] <smoser> the services are 'WantedBy' cloud-init.target
[13:38] <smoser> and the target is not enabled by default.
[13:41] <wCPO> Are you sure? In.my testing the generator enables the target?
[14:18] <Odd_Bloke> The generator wouldn't have to enable the target if it were enabled by default.
=== philroche_ is now known as philroche
[16:30] <johnsonshi_> Good morning folks! The 20.3 release recently exposed a new cloud-init bug that we've picked up from telemetry. The "report ready marker file" was being written before the "report ready call" actually happens while in preprovisioning. There have been several instances where the marker file is written but the report ready call fails. The fix is at https://github.com/canonical/cloud-init/pull/590
=== johnsonshi_ is now known as johnsonshi
[16:52] <Odd_Bloke> johnsonshi: What is the impact of this issue on affected systems?
[17:03] <johnsonshi> Odd_Bloke: Upon the occasional random reboot initiated by the platform, after the VM comes back up, cloud-init sees that the "report ready marker file" already exists. It immediately moves to poll for reprovisiondata instead of attempting to report ready again in preprovisioning.
[17:03] <johnsonshi> This causes several preprovisioned VMs to fail.
[17:04] <Odd_Bloke> Aha, right, I missed "preprovisioning" in your first statement.  Presumably there is no user impact, if you're catching these instances before they're released?
[17:04] <johnsonshi> Yup there is no direct user impact
[17:04] <johnsonshi> They are being caught during preprovisioning of the VMs.
[17:05] <johnsonshi> Hehe the DataSourceAzure codebase is a mess which is why the incorrect report ready marker file bug was missed for years :D
[17:09] <johnsonshi> Odd_Bloke: which we are all working towrads improving. Thanks for the prompt reviews as always!
[17:15] <johnsonshi> Odd_Bloke: We'll be discussing internally and continue monitoring. We'll want to see if it causes too much trouble before evaluating the hot fix approach. I do think they're rare, the cloud images have been out for a week now.
[17:20] <wCPO> Odd_Bloke: So what is best practice? Should I ask the ArchLinux package maintainer to run "systemctl enable cloud-<something>" as part of the installation? The Redhat package does that: https://github.com/canonical/cloud-init/blob/master/packages/redhat/cloud-init.spec.in#L130
[18:01] <meena> I'm very curious to see these new integration tests!!
=== tds2 is now known as tds
[18:45] <Odd_Bloke> meena: https://github.com/canonical/cloud-init/pull/592/ is the first test in the new style.
[18:48] <Odd_Bloke> (And https://cloudinit.readthedocs.io/en/latest/topics/integration_tests.html is the documentation.)
[18:49] <meena> Odd_Bloke, that looks really useful
[18:50] <Odd_Bloke> Yeah, falcojr did a really good job with the framework, I think.
[18:58] <Odd_Bloke> falcojr: Very small tweak to the PR template: https://github.com/canonical/cloud-init/pull/597
[19:47] <Odd_Bloke> wCPO: IIRC, an enabled service means "can be started", not "will be started", so I think they should be enabled.  Let me double check what the Ubuntu packaging does.
[19:48] <Odd_Bloke> Yep, looks like it's enabled there too.
[19:49] <meena> Odd_Bloke:  did you create https://bugs.launchpad.net/cloud-init/+bug/1884607 ?
[19:49] <ubot5> Ubuntu bug 1884607 in cloud-init "cloudinit.net refactor: generate_fallback_config" [Low,Triaged]
[19:49] <meena> never mind, it's from june
[19:51] <Odd_Bloke> meena: Yep, I reported a bug for every function that needs refactoring, they're all tagged `net-refactor`.
[19:53] <meena> Odd_Bloke: i looked for it the other day, but couldn't find it
[19:56] <wCPO> Odd_Bloke: I see.. The setup.py script should probably "enable" them then..
=== waxfire2 is now known as waxfire
[20:07] <Odd_Bloke> wCPO: We don't really expect people to use setup.py to install cloud-init into a system on which it should run; that should really be done via distro packages because of how closely integrated into boot cloud-init is, and so setup.py is more of a utility for packagers.
[20:08] <wCPO> Odd_Bloke: I'm not using setup.py the packager is, but setup.py should enable the services right?
[20:09] <Odd_Bloke> wCPO: I'm not familiar with many other projects that have systemd units to install, but I don't believe that would be standard for a setup.py installation: enablement is done by installing symlinks into paths that systemd "owns", and I don't think we can reliably do that in our packaging.
[20:10] <Odd_Bloke> (We don't even do that in our Ubuntu packaging; debhelper takes care of enabling services at install time automatically.)
[20:20] <wCPO> It shouldn't be that hard, but setup.py does not support symlinks it seems.
[20:22] <Odd_Bloke> Right; Python packages can be installed on Windows, they aren't the tool for packaging GNU/Linux system software.
[20:24] <wCPO> Kinda make sense. It would be nice though, if it could be documented that it is expected for the packer to enable the services.