[16:51] <blackboxsw> Thanks falcojr for putting up the PRs for cloud-init SRU in Ubuntu. reviewing them now.
[17:10] <blackboxsw> falcojr: I think we forgot to add Upcloud to those PRs in debian/cloud-init.templates*pot  and looks like we probably need to add that to ubuntu/devel too and perform a minor upload into hirsute for that change too
[17:11] <blackboxsw> https://github.com/canonical/cloud-init/pull/851#pullrequestreview-617777891
[17:12] <falcojr> ooooooh, yeah, inside the card I saw RbxCloud and thought we were doing that instead of UpCloud
[17:14] <blackboxsw> sorry falcojr , my bad on the trello card creation
[17:14] <blackboxsw> so I think if we are going to SRU that change, we also need another hisute upload which enables UpCloud  too.
[17:14] <falcojr> yeah
[17:14] <blackboxsw> if you want to gen that ubuntu/devel branch I'll review it a dput
[17:14] <falcojr> I'll make the changes
[17:15] <blackboxsw> *and dput. thanks
[17:20] <falcojr> blackboxsw: hirsute: https://github.com/canonical/cloud-init/pull/855
[17:21] <blackboxsw> thanks reviewing now
[17:24] <blackboxsw> falcojr: I think we probably need a new cloud-init bug for the enabling of UpCloud since we are going to SRU this functionality kindof simpler than https://bugs.launchpad.net/bugs/1762773
[17:27] <falcojr> blackboxsw: I'm not sure I follow. Why does this require a separate bug?
[17:31] <blackboxsw> falcojr: only that any functional changes that we SRU need a bug because they are not specifically involved in our SRU exception process I thought. Since this is a debian packaging specific change related to only the given distro and not upstream commits
[17:32] <blackboxsw> s/distro/specific Ubuntu release/
[17:35] <falcojr> can I simply reference https://github.com/canonical/cloud-init/pull/743 ? We have a lot of functional changes these days that don't have specific bug numbers. Or are you saying that because it's debian packaging specific change that it needs a bug?
[17:35] <blackboxsw> falcojr: I'm trying to look at prior art, maybe we don't actually need a process bug for all debian/template changes. I may be making that up
[17:37] <blackboxsw> falcojr: you are right. no bug needed
[17:37] <blackboxsw> the IBM one was a one-off where a bug was filed because we forgot to enable it
[17:38] <blackboxsw> not because it was required
[17:38] <falcojr> sounds good...I've pushed to the rest of the branches the UpCloud change too
[17:42] <blackboxsw> falcojr: your hirsute visual diff looks strange. did you do a `dch -i` and a new line for debian/cloud-init.templates: enable UpCloud by default ?
[17:44] <blackboxsw> I've force pushed my ubuntu/devel to https://github.com/blackboxsw/cloud-init/tree/ubuntu/devel
[17:44] <blackboxsw> as a comparison point
[17:52] <blackboxsw> falcojr: I think we need a new changelog entry in ubuntu/devel and we need to now also run debconf-updatepo on a few of those PRs to update debian/po/templates.pot
[17:54] <falcojr> blackboxsw: sorry, taking a lunch break now
[17:57] <blackboxsw> same. good idea
[19:17] <falcojr> blackboxsw: I'm assuming I need to make the po changes across all the releases?
[19:21] <blackboxsw> falcojr: I don't think paride backported that functionality to xenial, bionic or focal
[19:22] <blackboxsw> just groovy and hirsute
[19:22] <blackboxsw> I think he stopped on the earlier series to avoid churn
[19:22] <blackboxsw> yeah I see no debian/cloud-init.po files on X B F
[19:22] <blackboxsw> yeah I see no debian/cloud-init.pot files on X B F
[19:23] <falcojr> ah, gotcha
[19:24] <falcojr> wait, I see it on focal
[19:24] <blackboxsw> sorry I mean debian/po/templates.pot
[19:24] <falcojr> well...at least debain/po directory
[19:24] <blackboxsw> right I just saw that to
[19:24] <blackboxsw> so no on xenial and bionic
[19:24] <blackboxsw> but yes on focal groovy
[19:25] <blackboxsw> but yes on focal groovy hirsute
[19:25] <falcojr> and actually xenial has them too :D
[19:25] <falcojr> I wonder if bionic was missed by accident
[19:28] <hamalq> #cloud-config
[19:28] <hamalq> ---
[19:28] <hamalq> hostname: hamza
[19:28] <hamalq> fqdn: hamaza.ows.oath.cloud.
[19:28] <hamalq> preserve_hostname: true
[19:28] <hamalq> hi am using the configuration above in creating an insttance but the hostname always become localhost
[19:28] <hamalq> am i missing something
[19:29] <hamalq> ?
[19:30] <falcojr> hamalq: I think you want preserve_hostname: false
[19:31] <hamalq> ` preserve_hostname is set, then the hostname will not be altered.`
[19:32] <hamalq> i want the hostname to be short hostname
[19:38] <hamalq> mmm sorrrry i get it now
[19:39] <falcojr> yeah, preserve_hostname really just means "don't touch anything"
[19:42] <hamalq> am trying to make a rhel machine take the short hostname
[19:42] <hamalq> which does not work at all
[19:43] <blackboxsw> hamalq: this works for me on ubuntu using `lxc launch ubuntu-daily:xenial tmp-x -c user.user-data="$(cat 1.yaml)"`     https://paste.ubuntu.com/p/Y9yX8qJgXF/
[19:43] <blackboxsw> if that content from the pastebin is in a file called 1.yaml
[19:45] <blackboxsw> falcojr:bionic is weird.
[19:46] <blackboxsw> it was in there in 2016
[19:46] <blackboxsw> from comittish 7b0efb97c3667d4d1335e384433877a13e065380
[19:47] <blackboxsw> falcojr: I think we want something like this commit in bionic 1d88413b4e22408c0db24eed09c7a8daa84d0cb4 but checking it out now
[19:47] <hamalq> i just tried that no luck rhel always take FQDN
[19:48] <blackboxsw> hamalq: this reminds me of a bug/discussion, let's see if I can find that
[19:49] <blackboxsw> hamalq: https://bugs.launchpad.net/cloud-init/+bug/1724414
[19:51] <blackboxsw> hamalq: if someone wanted to submit a change to that default behavior it'd be here https://github.com/canonical/cloud-init/blob/master/cloudinit/distros/rhel.py#L94-L99
[19:51] <hamalq> blackboxsw: i can do the change
[19:52] <blackboxsw> we'd have to push that up for review and get redhat and or centOS folks in on the review as that might be a "breaking" change for some people who rely on fqdn being chosen, but that's where to start I think
[19:53] <hamalq> so i have to do the change then wait for review
[19:53] <blackboxsw> +1 all contributions welcome https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
[19:54] <falcojr> hamalq: I don't think we could accept the change at this point
[19:54] <blackboxsw> yeah you push up a PR, someone on upstream will review it, it'll land in tip.... then eventually make it into the given distros. It looks like from logic that if you don't provide fqdn that RedHat would use hostname
[19:54] <falcojr> we had a PR a few months ago to do exactly this, but we rejected it due to the regression potential
[19:54] <blackboxsw> ahh falcojr right, but did we discuss if that behavior could be behing another config flag? I can't really remember
[19:55] <blackboxsw> or did folks discuss that we just tell cloud-init community to not provide fqdn if they want to use hostname?
[19:56] <blackboxsw> or provide a runcmd: [hostnamectl set-hostname <myhost>]
[19:56] <falcojr> I'm not sure...there were multiple conversations IIRC
[19:57] <blackboxsw> yeah I'm thinking we should revisit the bug https://bugs.launchpad.net/cloud-init/+bug/1724414 tomorrow to get an update on it. Because if we aren't going to fix it, we should close this bug I think as wontfix
[19:58] <falcojr> +1, I'll add it to discuss
[19:58] <blackboxsw> in the meantime, wouldn't rhel-users be able to supply hostname: <something>   and no fqdn: and rhel should prefer hostname only
[19:58] <blackboxsw> at least I *think* so via https://github.com/canonical/cloud-init/blob/master/cloudinit/distros/rhel.py#L94-L99
[19:59] <hamalq> an option can be added to enable the short hostname behaviour
[20:01] <blackboxsw> hamalq: what would be your desired behavior in this case? if fqdn is supplied and hostname, are you expecting aliases for fqdn, but the ability to `ping/ssh hamza` etc?
[20:01] <falcojr> also, as more context: https://bugs.launchpad.net/cloud-init/+bug/1076759
[20:01] <falcojr> is the original reason rhel defaults to fqdn
[20:02] <hamalq> According to RFC 1035, the FQDN could up to 255 bytes. Setting hostname to FQDN will fail if FQDN > 64 byets.
[20:02] <falcojr> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-sysconfig is the updated dead link there. The hostname goes into /etc/sysconfig/network and needs to be fqdn......or at least used to
[20:05] <blackboxsw> falcojr: approved ubuntu/devel. I'm running sbuilt and will push in ~5 mins
[20:05] <hamalq> yes that true , but it says it could be any string
[20:09] <hamalq> blackboxsw: if the hostname is provided the hostname should be taken
[20:10] <hamalq> and the fqdn can be used for https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/ch-sysconfig
[20:12] <blackboxsw> hamalq: ok I think we'll look at this again tomorrow when Odd_Bloke also returns as he had some opinions on this too. We have a community office hours meeting tomorrow 17:15 UTC if you happen to be available
[20:13] <blackboxsw> we just chat in this IRC channel (in case you hadn't seen it before)
[20:28] <blackboxsw> falcojr: not sure what we want to do about ubuntu/bionic lack of translation files for cloud-init.templates at the moment.
[20:28] <blackboxsw> it's not critical, but it is a gap in behavior across Ubuntu releases
[20:29] <blackboxsw> we can take it as a bug or a trello card for next SRU.
[20:29] <blackboxsw> it's been this way a while
[20:30] <falcojr> I can add a card to discuss it
[20:30] <blackboxsw> yeah sounds good. I think we can get through groovy and focal. but need to leave xenial and bionic incomplete.
[20:31] <blackboxsw> because we can't run debconf-updatepo anyway on xenial as it is
[20:31] <blackboxsw> or I can't at least.
[20:31] <blackboxsw>  /usr/bin/xgettext: error while opening "../grub.templates.h" for reading: No such file or directory
[20:41] <blackboxsw> falcojr: I think we have a typo in Upcloud vs UpCloud in templates https://github.com/canonical/cloud-init/pull/852/files
[20:41] <blackboxsw> on focal
[20:45] <falcojr> good catch, thanks
[20:48] <falcojr> blackboxsw: for approved ones, should I merge before or after upload (or does it matter)?
[20:52] <blackboxsw> falcojr:  since I've built and dput the hirsute version cloud-init it might be easier for me to build-and-push since it'll reference the upstream orig.tar.gz in ../out on my local system. otherwise you have to download the orig.tar.gz into ../out  and then you can run build-and-push.
[20:52] <blackboxsw> hirsute is already uploade .
[20:52] <blackboxsw> hirsute is already uploaded.
[20:52] <blackboxsw> and I'm mid sbuilt-id on focal.
[20:53] <blackboxsw> I was going to just push both groovy and focal and we can sort what we want to do w/ bionic/xenial tomorrow
[20:54] <blackboxsw> if that's okay (at least I'll get those sponsorship points to trade in for a candy cane at the end of the year)
[20:55] <blackboxsw> and generally, if you are using uss-tableflip/scripts/build-and-push it'll do the upload, then the merge afterwards I think
[20:56] <blackboxsw> and actually, the more I think about it. we can still queue the uploads on xenial nad bionic without the translation stuff as we won't actually burn any versions if we decide we want to add/fix  pot files on xenial and bionic for this release
[20:58] <falcojr> +1 on queuing the uploads today
[21:13] <blackboxsw> ok queuing groovy now
[21:16] <blackboxsw> falcojr: since you and Odd_Bloke get in waay before me. I'll queue the uploads after final review here for X, B, F and G. if alls good then you can hit up SRU folks in #ubuntu-release tomorrow early if you and Dan are of the same mind on skipping translation stuff for X and B
[21:17] <blackboxsw> since I think it already doesn't exist (well) in either series
[21:18] <blackboxsw> falcojr: you need a debconf-updatepo againt on your ubuntu/focal branch
[21:19] <falcojr> https://github.com/canonical/cloud-init/pull/852/commits/fc89817101d09cd8b557a3363a531e8776cc4903
[21:19] <falcojr> blackboxsw: it's in that commit
[21:21] <falcojr> (and same for the other releases)
[21:22] <blackboxsw> falcojr: in that commit I see +msgid "Upcloud: Upcloud"
[21:22] <blackboxsw> shouldn't it be UpCloud: UpCloud
[21:22] <blackboxsw> camelCase?
[21:22] <falcojr> !@#$%
[21:22] <blackboxsw> qbert strikes again
[21:22] <falcojr> I gotcha now
[21:23] <blackboxsw> I think all the other releases were good on the camelCase front
[21:24] <falcojr> pushed
[21:25] <blackboxsw> bionic uploaded
[21:26] <blackboxsw> working on focal now
[21:36] <blackboxsw> focal uploaded
[23:24] <blackboxsw> ok xenial/bionic uplaoded too
[23:25] <blackboxsw> uploaded even