=== vrubiolo1 is now known as vrubiolo
=== vrubiolo2 is now known as vrubiolo
[10:09] <toolz> any of you know why cant I make cloud-init work successfully on archlinux? https://pastebin.com/CDpPHcCR
[10:10] <toolz> it sets the network, but it doesnt growpart
[10:10] <toolz> and I see that error:
[10:11] <toolz> this is cloud.cfg https://pastebin.com/5MwQPAJ4
[10:13] <toolz> cloud-init 20.4
[14:32] <Odd_Bloke> toolz: Looks to me like you have tabs ("\t") in your input, which I believe makes it invalid YAML; try replacing them with spaces.
[14:49] <Odd_Bloke> bashfulrobot: Did you solve your network-config issue?  (The "[]" on the first line of your YAML looks suspect to me. :)
[16:01] <bashfulrobot> Odd_Bloke: not yet. The `[]` is (from my understanding) the way you allow the yaml to specify against all interfaces. The problem I have is that I don't know the interface id at the time of writing (used in automation). So the idea was to specify no interface, and then use the match pattern to apply on my Ubuntu system.
[17:06] <qbd> hello. i have a problem with cloud-init where I can't connect using the public key of the user I'm adding after it's done
[17:29] <Odd_Bloke> bashfulrobot: Hmm, not sure where you're getting that from; that's not valid YAML as-is ("expected <block end>, but found '<block mapping start>'" on the dhcp4 line).
[17:30] <Odd_Bloke> Removing the " []" from that line does make it valid YAML.
[17:33] <Odd_Bloke> bashfulrobot: I think you want something more like https://paste.ubuntu.com/p/5k7bxQtX7V/
[17:58] <bashfulrobot> Odd_Bloke: I found it on an article I was reading. I never knew about that `all` keyword. I'll give this a try! if that's not valid yeah more, than that explains probably why it was dying.
[18:19] <Odd_Bloke> bashfulrobot: To be clear, "all" is not a keyword, it's an arbitrary identifier.
[18:19] <Odd_Bloke> (See "Device configuration IDs" in https://netplan.io/reference/)
[18:23] <bashfulrobot> @Odd_Bloke: ah ok. But is valid for cloud-init.
[18:24] <bashfulrobot> Oh heck. They are just a "label". I thought they had to match the real interface!
[18:25] <Odd_Bloke> bashfulrobot: There's a "special case" where if you don't specify a match explicitly then the label will be matched against interface names.
[18:26] <bashfulrobot> Ok, that makes sense.
[18:26] <Odd_Bloke> (So `enp5s0: ...` would be applied to enp5s0, `enp5s0: ..., match: name: "enp6s0"` would be applied to enp6s0.)
[18:26] <bashfulrobot> Thank you so much for the clarification!!!!
[18:26] <Odd_Bloke> :)
=== hggdh_ is now known as hggdh
=== ijohnson is now known as ijohnson|lunch
[19:18] <qbd> hello, sorry my internet disconnected after my question
[19:20] <bashfulrobot> Odd_Bloke: confirmed. All is now working.
[19:20] <bashfulrobot> I really appreciate it.
[19:20] <qbd> I wasn't able to get my cloud-init users working
[19:26] <qbd> This is the relevant section : https://pastebin.com/DEfegFZt
[19:26] <qbd> Obviously with the correct key filled in
[19:32] <Odd_Bloke> qbd: What's the specific problem?
[19:33] <Odd_Bloke> You do need #cloud-config as the first line of your config (though perhaps that's already present in the full config).
[19:34] <qbd> yes that line is present. after the cloud-init is finished, i cannot connect using my private key on the corresponding machine
[19:35] <qbd> other parameters such as the hostname etc seem to have been executed successfully
=== ijohnson|lunch is now known as ijohnson
[19:52] <Odd_Bloke> Anyone else seeing "ImportError: cannot import name 'status_tag_messages' from 'knack.util'" when trying to run the Azure integration tests?
[19:53] <qbd> Odd_Bloke should I post the full config ?
[19:54] <Odd_Bloke> qbd: I've reproduced this: https://paste.ubuntu.com/p/P4psnJqKWF/
[19:54] <Odd_Bloke> That's from cloud-init.log.
[19:55] <Odd_Bloke> I don't have time to look into it much (about to go into a meeting), but I think the problem is that cloud-init creates the user-matching group because it's in config, and then useradd chokes on creating the user, because we've already created the group.
[19:55] <qbd> I couldn't check the logs because I can't login :(
[19:55] <Odd_Bloke> Probably just dropping out the `groups: borg` part would address it.
[19:56] <Odd_Bloke> https://bugs.launchpad.net/cloud-init/+bug/1870310 sounds at least related.
[19:56] <ubot5> Ubuntu bug 1870310 in cloud-init "Explicit addition of a user's primary_group breaks the user creation" [Medium,Triaged]
[19:57] <qbd> I'll try that and get back to you about it later. Maybe I'm just doing something wrong
[19:57] <Odd_Bloke> I don't think so: I think this is a cloud-init bug that you're hitting.
[19:57] <Odd_Bloke> But I _think_ you can avoid triggering the buggy behaviour by not specifying a user's primary group in their groups list.
[19:58] <qbd> my intention is to add them to the same group as their username
[19:59] <Odd_Bloke> Right, Ubuntu at least will do that automatically.
[19:59] <Odd_Bloke> And, indeed, it's that automatic addition that's failing, I believe.
[20:00] <qbd> thank you, gonna try this tomorrow
[22:00] <AnhVoMSFT> "Cloud-init v. 19.4 running 'single' at Tue, 19 Jan 2021 14:09:29 +0000. Up 26804.24 seconds" - what does this mean? I have only seen init-local, init, config, final. Why is there a "single" stage?
[22:00] <rharper> manual invocation
[22:00] <rharper> single is used to run just one config module
[22:01] <rharper> typically re-running one that's already completed.  cloud-init --config my-new-user-data.cfg single --name cc_ntp --frequency=always  ;  # re-run cc_ntp module with local user-data file, run even if it's already run before
[22:01] <rharper> AnhVoMSFT: ^
[22:37] <AnhVoMSFT> I see - so the user/customer ran cloud-init manually
[23:21] <rharper> AnhVoMSFT: yeah, in stock images, single is not ever run; so either someone packed their own image or manually ran it;