=== vrubiolo1 is now known as vrubiolo
wCPOShould the cloud-init package enable the relevant systemd services or should the user do it?11:19
meenawCPO: depends?12:04
wCPOmeena: Okay? What is best practice?12:12
wCPOcloud-init-generator only enables the cloud-init.target, the services still needs to be enabled manually AFAIK12:13
meenawhat's cloud-init-generator?12:14
wCPOmeena: https://github.com/canonical/cloud-init/blob/master/systemd/cloud-init-generator.tmpl12:15
smosermeena: the services are wanted by the target13:34
smoserso the generator just controls whether or not hte target is active13:34
smoserso wCPO , the answer to your question is:13:35
smoser on systemd system, the package should place the generator (cloud-init-generator) in /lib/systemd/systemd-generators13:37
smoserand should install the systemd units and target as is.13:37
smoserthe services are 'WantedBy' cloud-init.target13:38
smoserand the target is not enabled by default.13:38
wCPOAre you sure? In.my testing the generator enables the target?13:41
Odd_BlokeThe generator wouldn't have to enable the target if it were enabled by default.14:18
=== philroche_ is now known as philroche
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/59016:30
=== johnsonshi_ is now known as johnsonshi
Odd_Blokejohnsonshi: What is the impact of this issue on affected systems?16:52
johnsonshiOdd_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
johnsonshiThis causes several preprovisioned VMs to fail.17:03
Odd_BlokeAha, 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
johnsonshiYup there is no direct user impact17:04
johnsonshiThey are being caught during preprovisioning of the VMs.17:04
johnsonshiHehe the DataSourceAzure codebase is a mess which is why the incorrect report ready marker file bug was missed for years :D17:05
johnsonshiOdd_Bloke: which we are all working towrads improving. Thanks for the prompt reviews as always!17:09
johnsonshiOdd_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:15
wCPOOdd_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#L13017:20
meenaI'm very curious to see these new integration tests!!18:01
=== tds2 is now known as tds
Odd_Blokemeena: https://github.com/canonical/cloud-init/pull/592/ is the first test in the new style.18:45
Odd_Bloke(And https://cloudinit.readthedocs.io/en/latest/topics/integration_tests.html is the documentation.)18:48
meenaOdd_Bloke, that looks really useful18:49
Odd_BlokeYeah, falcojr did a really good job with the framework, I think.18:50
Odd_Blokefalcojr: Very small tweak to the PR template: https://github.com/canonical/cloud-init/pull/59718:58
Odd_BlokewCPO: 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:47
Odd_BlokeYep, looks like it's enabled there too.19:48
meenaOdd_Bloke:  did you create https://bugs.launchpad.net/cloud-init/+bug/1884607 ?19:49
ubot5Ubuntu bug 1884607 in cloud-init "cloudinit.net refactor: generate_fallback_config" [Low,Triaged]19:49
meenanever mind, it's from june19:49
Odd_Blokemeena: Yep, I reported a bug for every function that needs refactoring, they're all tagged `net-refactor`.19:51
meenaOdd_Bloke: i looked for it the other day, but couldn't find it19:53
wCPOOdd_Bloke: I see.. The setup.py script should probably "enable" them then..19:56
=== waxfire2 is now known as waxfire
Odd_BlokewCPO: 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:07
wCPOOdd_Bloke: I'm not using setup.py the packager is, but setup.py should enable the services right?20:08
Odd_BlokewCPO: 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:09
Odd_Bloke(We don't even do that in our Ubuntu packaging; debhelper takes care of enabling services at install time automatically.)20:10
wCPOIt shouldn't be that hard, but setup.py does not support symlinks it seems.20:20
Odd_BlokeRight; Python packages can be installed on Windows, they aren't the tool for packaging GNU/Linux system software.20:22
wCPOKinda make sense. It would be nice though, if it could be documented that it is expected for the packer to enable the services.20:24

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!