=== vrubiolo1 is now known as vrubiolo
[07:08] <otubo> powersj, I'm gonna take a look. Thanks!
[10:28] <andras-kovacs> huh... I didn't know Azure can be this terrible... I made a VM template with cloud-init installed in it, but disabled. My intention was to start to use it with Azure's own telemetry-collector whatnot than change to cloud-init as soon as possible.
[10:28] <andras-kovacs> But it says "[ProvisionError] cloud-init appears to be running, this is not expected, cannot continue."
[10:29] <andras-kovacs> I found a bug and the reason of it is/are probably the dhclient + NetworkManager scripts, but still...
[10:29] <andras-kovacs> I believed it can't be worse after the fixed-size IDE connected vhd files. But actually, it can.
[10:31] <andras-kovacs> https://github.com/Azure/WALinuxAgent/issues/806
[10:32] <andras-kovacs> I was wondering... why do they need to re-invent the wheel?
[11:37] <andras-kovacs> Even more funnier this waagent doesn't even log it's error on error level to journal. :D
[12:54] <StyXman> is it possble that if I deploy a user, setting its password  and marking it as expired, the password is set *after* it was marked as expired, so this password set overwrites the expiration date? BTW, there is no expriration date in /etc/shadow, only last change date and max password age
[12:56] <StyXman> here's my config: https://dpaste.org/4g89
[13:21] <StyXman> in fact it's a bug: the image I'm using has a adduser who ignores --expirredate and there seems to be a function to go arund such bugs, but it doesn't seem to be used
[13:53] <Odd_Bloke> StyXman: Are you saying it's a bug in the image you're using, or you think it's a bug in cloud-init?
[13:59] <StyXman> https://bugs.launchpad.net/cloud-init/+bug/1872995
[13:59] <ubot5> Ubuntu bug 1872995 in cloud-init "expiredate is not working if also setting a password." [Undecided,New]
[14:36] <otubo> Odd_Bloke, powersj by the way, just found another bug on the swap file stuff. But won't make it to the release cut this time. Can't make upstream/backport in less than an hour.
[14:36] <Odd_Bloke> otubo: OK, hm, should we back out the original change so we can reland it with these fixes applied?
[14:36] <otubo> Odd_Bloke, powersj I'll post another PR soon, together with a unittest.
[14:37] <otubo> Odd_Bloke, that part is correct, the assignment should be after the try/except. The bug is at create_swapfile()
[14:38] <otubo> cmd = ['fallocate', '-l', '%dM' % size, fname] ---> is treating size as %d when it is %s
[14:38] <otubo> errmsg = "Failed to create swapfile '%s' of size %dMB via %s: %s" ---> here too
[14:45] <otubo> Odd_Bloke, I'll fix it and include the unittest by tomorrow. No need to drop anything right now.
[14:45] <powersj> otubo, thank you!
[16:12] <mutantturkey> so i have only enabled a few specific modules from cloud init, but another thing cloud-init is doing is setting the 'hostname'
[16:12] <mutantturkey> i don't actually want it to do so, is there a way to prevent it from overwriting my hostname i set in my custom image?
[16:13] <blackboxsw> mutantturkey: the hostname gets set early in boot by cloud-init to fix a number of platforms that need hostname set before the initial dhcp request..... I'll get you where that's done.
[16:13] <blackboxsw> and we'll see if it can be disabled
[16:13] <mutantturkey> is it    199 ^[[0;32m    digitalocean: /usr/lib/python3/dist-packages/cloudinit/config/cc_set_hostname.py^[[0m
[16:13] <mutantturkey> sorry the output got munged
[16:14] <mutantturkey> i did find a "echo "preserve_hostname: true" > /etc/cloud/cloud.cfg.d/99_hostname.cfg" but i wasn't sure if that was accurate
[16:15] <blackboxsw> mutantturkey: it's in cloudinit/cmd/main.py
[16:15] <blackboxsw> mutantturkey: https://github.com/canonical/cloud-init/blob/master/cloudinit/cmd/main.py#L698-L713
[16:16] <blackboxsw> so it's set only if user-data or meta-data on the cloud provides that value
[16:16] <blackboxsw> but yes, ultimately calls cc_set_hostname
[16:17] <andras-kovacs> could you point me to the right direction to find a cloud.cfg which works in Azure? I mean which can set the hostname, etc. from the meta data.
[16:19] <blackboxsw> mutantturkey: you can check if DO provides that hostname in metadata with `cloud-init query --all`
[16:20]  * andras-kovacs sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/SZJZxEKrgcFXnlWGZLCUSoed >
[16:20] <andras-kovacs> but cloud-init query -a gives [] nulland ""
[16:22] <mutantturkey> blackboxsw: cloud-int query --all: error argument subcommand: invalid choice 'query'
[16:23] <mutantturkey> cloud-init -v: 15:58 <@blackboxsw> but yes, ultimately calls cc_set_hostname
[16:23] <mutantturkey> sorry, /usr/bin/cloud-init 18.3
[16:23] <andras-kovacs> but I can read the meta data with curl... hmmm..
[16:23] <andras-kovacs> mutantturkey: cloud-init query -a
[16:24] <andras-kovacs> mutantturkey: I like your name. Do you watch SouthPark?
[16:24] <Odd_Bloke> andras-kovacs: Where is your current cloud.cfg coming from?
[16:24] <mutantturkey> andras-kovacs: no, i mean i have seen it, but i dont know the reference
[16:24] <Odd_Bloke> andras-kovacs: mutantturkey: 18.3 predates `cloud-init query` being available, I believe.
[16:24] <mutantturkey> Odd_Bloke: seems so
[16:25] <mutantturkey> i am fairly certain that the hostname is set by cloud init, as it sets it to the first part name of the DO box. (x.y.z: it is set to x)
[16:25] <mutantturkey> and the logs confirm
[16:26] <mutantturkey> Running command ['hostname', xzy]
[16:26] <andras-kovacs> Odd_Bloke: from the package, the default. So I need to play around with it. It worked so good with openstack for the first try. But Azure is really different. Do you have a link or sg. for a working sample config? I saw the one in the doc but I got confused because of the __builtin__ and dhclient_lease_file part.
[16:27] <mutantturkey> yeah; 2020-04-14 17:59:09,190 - util.py[DEBUG]: Read 51 bytes from /var/lib/cloud/data/set-hostname
[16:27] <andras-kovacs> I don't know yet how to define the the lease file, because I use NetworkManager and it looks like /var/lib/NetworkManager/dhclient-5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease
[16:33] <Odd_Bloke> andras-kovacs: "the package" on what distro?  It works out of the box on Ubuntu, and I haven't heard of any other substantial issues.
[16:56] <andras-kovacs> RedHat 7.8. I could proceed further, but now I see: DataSourceAzure.py[WARNING]: Could not crawl Azure metadata: No Azure metadata found.
[17:20] <Vitto> Hello, I am a novice programmer and I am trying to use the cloud init functionality via Scaleway API but cannot seem to get it to work. I have a working cloud init shellscript that does its job when launched via web dashboard. Instead, when I try to submit it via API it seems that the cloud init boot does detect the script. Is anyone able to help
[17:20] <Vitto> me?
[17:23] <rharper> hi Vitto  one possible issue is how the API attaches the user-data to their instance ... some platforms require the user-data content (cloud-config yaml) to be base64 encoded ... is there any API documentation on scaleway that migth help ?
[17:30] <johnsonshi> Hi guys, I have a question regarding trying to specify my own systemd unit to start in the middle of cloud-init.service and cloud-config.service. The question is here at: https://paste.ubuntu.com/p/tR6vMm6SGd/
[17:44] <Vitto> rharper this is the user data section of the scaleway API https://developers.scaleway.com/en/products/instance/api/#user-data-35f60e, it does not mention anything regarding base64 encoding, I'll ask them directly in the meanwhile.
[17:55] <mutantturkey> so documentation says hostname can be specified via hostname key, in my cloud-init ustom config would that be
[17:55] <mutantturkey> hostname: myname
[18:10] <mutantturkey> that worked, and since i know the expected hostname, my problem is solved. dope
[20:14] <Odd_Bloke> blackboxsw: rharper: https://github.com/canonical/cloud-init/pull/316 should fix swap file creation in master; I'd appreciate a speedy review so we can discuss cherry-picking it to fix focal before Final Freeze (tomorrow :p).
[20:14] <Odd_Bloke> otubo: Apologies to perhaps duplicate your work; today is the last day to get fixes into the next Ubuntu release on day one, so this is urgent for us. :)
[20:23] <blackboxsw> Odd_Bloke: +1 grabbing
[20:35] <blackboxsw> Odd_Bloke: nit comment  https://github.com/canonical/cloud-init/pull/316#pullrequestreview-394115233
[20:47] <blackboxsw> Odd_Bloke: I see in the failure path case on cc_mounts:create_swapfile that if create_swap fails, it deletes fname, but then create_swapfile proceeds to     util.chmod(fname, 0o600)
[20:47] <blackboxsw> which should no longer exist
[20:48] <blackboxsw> is it worth create_swap raising in the util.ProcessExecutionError failure path?
[20:48] <blackboxsw> just after the warning and del_file
[20:48] <Odd_Bloke> blackboxsw: I'm just trying to apply the minimal fix that gets previously-working configurations to continue working.
[20:49] <Odd_Bloke> (I'm not saying there isn't work to be done to improve the failure mode, but that's not RC.)
[20:49] <blackboxsw> good pt. so for that, we can avoid the failure path test case (because it exposes this error).  I was trying to write up a failure_path test to get coverage on the errmsg  template as well
[20:50] <blackboxsw> so we are good with happy_path test only
[20:50] <johnsonshi> Hi guys, does including both "After=cloud-config.target" and "Before=cloud-config.service"
[20:50] <johnsonshi>  in a custom systemd unit ensure that the custom systemd unit is started after cloud-init.service finishes but before cloud-config.service starts?
[20:50] <Odd_Bloke> blackboxsw: Responded to your comment; will also work to improve the tests here.
[20:51] <Odd_Bloke> (But I don't think we should block landing this on improved tests; it's completely broken right now, I can't make it worse with this change. :p)
[20:51] <blackboxsw> johnsonshi:  maybe After=network-online.target cloud-config.target and Before cloud-config.service
[20:51] <blackboxsw> Odd_Bloke: +1 on your PR with that in mind that we will have a followup
[20:52] <Odd_Bloke> blackboxsw: Ack, thanks.  (Can you mark that in GH so I can land it?)
[20:53] <blackboxsw> Odd_Bloke: merged
[20:55] <johnsonshi> blackboxsw: Thanks for the that tip! Hopefully this time the custom systemd unit should always run in the correct order. Thanks!
[21:02] <rharper> johnsonshi: I think your initial config is sufficient;   cloud-config.target already has After on cloud-init.service; and cloud-config.service runs after cloud-config.target;
[21:11] <blackboxsw> Odd_Bloke: rharper https://github.com/canonical/cloud-init/pull/318
[21:12] <blackboxsw> cherry-pick release to review
[21:12] <Odd_Bloke> I'm not 100% sure how to replicate that locally currently, but that LGTM.
[21:14] <blackboxsw> Odd_Bloke: sorry added cmdline steps
[21:14] <blackboxsw> to the PR description
[21:28] <Odd_Bloke> blackboxsw: +1
[21:33] <Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/319 is the best I can do for additional tests; the sad path is actually broken more deeply than just the variable substitution (as you pointed out), so I'll leave it for now.
[21:33] <blackboxsw> thanks Odd_Bloke will look it over before tomorrow
[21:39] <blackboxsw> community notice: [ubuntu/focal-proposed] cloud-init 20.1-10-g71af48df-0ubuntu4 (Waiting for approval)
[21:39] <blackboxsw> we are hoping to release that swap file creation into Ubuntu Focal before LTS  release is final
=== vrubiolo1 is now known as vrubiolo