[19:20] <blackboxsw> community notice: the rename of cloud-init upstream/master branch to "main" is happening in an hour. The only impact should be that your local git clones will need the following steps:
[19:20] <blackboxsw> git fetch upstream    # or 'origin' depending on your config                    
[19:20] <blackboxsw> git checkout master                                                             
[19:20] <blackboxsw> git branch -m main                                                              
[19:20] <blackboxsw> git branch -u upstream/main
[19:21] <blackboxsw> All existing PRs should be migrated to target main automatically
[19:58] <blackboxsw> minor doc PR up https://github.com/canonical/cloud-init/pull/926
[19:58] <ubottu> Pull 926 in canonical/cloud-init "docs: fix stale links rename master branch to main" [Open]
[19:58] <blackboxsw> rename complete
[20:05] <blackboxsw> mail sent
=== nicolasbock_ is now known as nicolasbock
[20:44] <blackboxsw> falcojr: minor request changes on https://github.com/canonical/cloud-init/pull/923#pullrequestreview-686756747
[20:44] <ubottu> Pull 923 in canonical/cloud-init "Fix DNS in NetworkState (SC-133)" [Open]
[20:44] <blackboxsw> and approved if you minimally rename handle_individual_nameserver -> _handle_individual_nameserver
[20:53] <falcojr> blackboxsw: thanks, got some minor ones for you on  https://github.com/canonical/cloud-init/pull/926 also
[20:53] <ubottu> Pull 926 in canonical/cloud-init "docs: fix stale links rename master branch to main" [Open]
[20:55] <themachine> Is this an appropriate place to ask support questions?
[20:57] <blackboxsw> themachine: depends, ask away, if someone can help we will, if it's too deep in the weeds I'm sure we can point you to the right place
[20:57] <falcojr> themachine: sure! What's up?
[20:58] <blackboxsw> if we are looking for account credentials reset... probably not the right place :)
[20:58] <themachine> I'm just getting started with cloud-init, working on wrapping my head around things. Currently trying to just get the most basic of debian systems up with a #cloud-config that is only creating a user and setting a pass. My current issue is that the password does not appear to be getting set.
[20:59] <themachine> One moment as I upload my config
[21:00] <falcojr> for sharing configs, probably easiest to use https://paste.ubuntu.com/
[21:00] <themachine> https://termbin.com/0p3p
[21:01] <blackboxsw> +1 generally on your system you could try to first validate no Tracebacks in /var/log/cloud-init.log, you can also double check what the launched VM "saw" as your userdata with the following:
[21:01] <themachine> It's my understanding that the above config should set "testpass" as the password however it does not. Looking at the cloud-init.log though I do see that it does successfully create my user
[21:01] <blackboxsw> sudo cloud-init query userdata > ud.yaml; cloud-init devel schema -c ud.yaml --annotate
[21:02] <blackboxsw> checlking your link now
[21:02] <blackboxsw> themachine the first line needs to be #cloud-config
[21:02] <themachine> sorry, yes it does have that. Neglected it in my example.
[21:02] <blackboxsw> and the schema command I mentioned above would alert you to that I think
[21:02] <blackboxsw> ahh ok
[21:03] <falcojr> passwd needs to be hashed
[21:03] <falcojr> and you also need a lock_passwd: false
[21:03] <falcojr> lemme figure out how to hash the password again :)
[21:03] <themachine> aaaaaaaaahhhhhh
[21:03] <themachine> I can do the hashing no problem falcojr, thank you though
[21:04] <themachine> I was hashing but moved plain while troubleshooting
[21:04] <themachine> my issue is surely the lock_passwd though. Didn't realize it was true by default.
[21:04] <falcojr> main use case for cloud-init is ssh keys, so logging in through console can be a bit of a pain (and possible security risk)
[21:04] <themachine> I will be using ssh keys once I'm done.
[21:04] <themachine> Really just testing the waters and writing my own deployment script
[21:05] <falcojr> I *think* this should do it
[21:05] <falcojr> mkpasswd --method=SHA-512 --rounds=4096
[21:06] <themachine> yup, exactly what I'm using
[21:06] <themachine> the lock_passwd would be my issue, running a test now with that updated
[21:06] <blackboxsw> excellent. ok and yeah more docs on hashing here https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups
[21:09] <themachine> that was it
[21:09] <themachine> thank you very much gents
[21:16] <blackboxsw> https://github.com/canonical/cloud-init/pull/923#pullrequestreview-686826690  approved thx falcojr 
[21:16] <ubottu> Pull 923 in canonical/cloud-init "Fix DNS in NetworkState (SC-133)" [Open]
[21:29] <falcojr> blackboxsw: do our launchpad build recipes need to change because of the master->main change?
[21:30] <falcojr> I still have no idea how any of the lp stuff works
[21:31] <falcojr> I tried to rebuild the daily PPA to pull in my test changes, but it's not building the latest commit. Not sure if there's some sync step I'm missing or if it's forever stuck building the last commit we put on master unless we change it to main
[21:40] <blackboxsw> falcor I'll check it out and we can redocument it
[21:40] <blackboxsw> also we need to perform the jenkins syncgithub job to get latest commit
[21:40] <blackboxsw> into launchpad anyway
[21:41] <blackboxsw> falcojr: for reference https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-bionic https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-xenial etc etc
[21:41] <blackboxsw> yeah we need to change from master to main
[21:41] <blackboxsw> just edit the recipe body at the bottom
[21:41] <blackboxsw> I'm going through that now 
[21:43] <blackboxsw> and don't forget our friend https://code.launchpad.net/~cloud-init-dev/+recipe/cloud-init-daily-devel
[21:43] <blackboxsw> ok all updated. I'm kicking jenkins job now
[21:45] <blackboxsw> https://github.com/canonical/cloud-init/pull/923 merged
[21:45] <ubottu> Pull 923 in canonical/cloud-init "Fix DNS in NetworkState (SC-133)" [Merged]
[21:45] <falcojr> ahhh, thanks. The mirror job is what I was missing
[21:45] <falcojr> I ran the admin one instead
[21:45] <falcojr> thanks!
[21:47] <blackboxsw> falcojr: https://jenkins.ubuntu.com/server/job/cloud-init-github-mirror/1345/console ok looks like our job can't sync yet with the rename. might have to manually override to allow deletion of "master" branch
[21:47] <falcojr> yeah, just saw that
[21:47] <blackboxsw> yeah minor wrinkle. but I'm about to pickup pizza for a 4 y.o. bday party. I can peek later to sort if your EOD too
[21:48] <blackboxsw> take care gotta run
[21:54] <falcojr> thanks! I'm EOD-ish but got a few minutes to look while food cooks. If not we can look tomorrow
[22:09] <falcojr> I'm EOD too
[22:10] <falcojr> paride: is this something you can look at tomorrow? We renamed "master" to "main" in cloud-init, and the cloud-init-github-mirror job isn't happy  (see the console link a few messages up)
[22:26] <blackboxsw> I configured the default git branch in LP to main instead of master here https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+edit and then I performed a git push lp --delete master to remove that branch. I have a local copy if needed tomorrow. but I think that should settle the github sync job will test later tonight
[22:30] <falcojr> oh, so it was just an issue of the LP remote not having the branch? I thought it was local to the machine. 
[22:33] <blackboxsw> I think it was LP knew it had the branch and that it was default for the project and the fact that the jenkins script was trying to delete it due to the rename
[22:34] <blackboxsw> so I manually removed the branch name from LP so it shouldn't complain about deleting the default branch now due to the github rename
[22:34] <blackboxsw> that said master on LP was 2 commits off of tip of main, so we can recreate if something catastrophic happened
[23:18] <blackboxsw> confirmed github sync  job worked  nothing to see here paride :) https://jenkins.ubuntu.com/server/job/cloud-init-github-mirror/1346/