[00:21] <smoser> blackboxsw: i think
[00:21] <smoser> to my knowledge, no such commit is in master.
[00:21] <smoser> bah
[00:21] <smoser> paste. fail.
[00:22] <smoser> blackboxsw: i think https://github.com/canonical/cloud-init/pull/721 needs your re-review.
[02:14] <blackboxsw> smoser: thanks! on it tomorrow
[02:14] <blackboxsw> and many thanks to otubo for pushing and repushing and infinite patience etc
[09:44] <Xat`> I am looking for a way to provision an instance via cloud-init
[09:44] <Xat`> I want the provisioning to be run (or re-run) at demand
[09:46] <Xat`> I have used terraform to build the instance, then now I've just added the cloud-init config, but it does nothing
[09:55] <Xat`> is this possible ?
[13:30] <Odd_Bloke> blackboxsw: falcojr: I missed the UpCloud addition because it mentions "for SRU" in the title of the card, so I didn't think to check if it was needed in hirsute.
[13:35] <Odd_Bloke> Regarding the RHEL FQDN thing: I don't think we can justify changing that default without a substantial reason, and I haven't yet heard one.
[13:37] <Odd_Bloke> Xat`: o/ cloud-init only runs on boot by design, and only performs many of its actions on first boot (at which point it will perform "destructive" actions: not a problem for a first boot, but likely a problem for a running instance).  It's likely better used to bootstrap a provisioning system which does support running after boot.
[13:40] <Xat`> thanks Odd_Bloke
[13:50] <falcojr> Odd_Bloke: not sure how much you've read of yesterday's events, but "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"
[13:50] <falcojr> are you of the same mind?
[13:51] <falcojr> B doesn't seem to have any translation files at all, and X exits with an error when we try to run debconf-updatepo
[13:52] <falcojr> and we were thinking that shouldn't block this SRU (it's not a new problem), but wanted to double check with you
[13:56] <blackboxsw> falcojr: the uploads are already queued for all, just waiting on a discussion about translations as you mentioned https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=cloud-init https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=cloud-init https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=cloud-init
[13:56] <blackboxsw> https://launchpad.net/ubuntu/groovy/+queue?queue_state=1&queue_text=cloud-init
[13:56] <blackboxsw> so only thing left is to talk in #ubuntu-release to the SRU vanguard when agreed
[14:10] <BugzBunny> hey @Odd_Bloke It's still on my list. Just I haven't touch this issue yet
[14:33] <Odd_Bloke> blackboxsw: falcojr: I didn't fully understand all that, no: generally speaking, if it isn't a regression, it's not a problem.
[14:46] <blackboxsw> +1 Odd_Bloke/falcojr I think that means we are good for ping in #ubuntu-release for Ubuntu SRU
[15:48] <blackboxsw> community notice: 1.5 hours until office hours in this channel (mostly saying for my benefit)
[17:22] <Odd_Bloke> #startmeeting cloud-init bi-weekly office-hours
[17:22] <meetingology> Meeting started at 17:22:08 UTC.  The chair is Odd_Bloke.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[17:22] <meetingology> Available commands: action, commands, idea, info, link, nick
[17:22] <Odd_Bloke> #chair blackboxsw falcojr
[17:22] <meetingology> Current chairs: Odd_Bloke, blackboxsw, falcojr
[17:22] <blackboxsw> \0 woot thanks Odd_Bloke
[17:23] <Odd_Bloke> Hey folks, the cloud-init committers will be around for the next while, to answer any questions or have any discussions you're interested in having.
[17:23] <Odd_Bloke> blackboxsw posted a status update to Discourse earlier today.
[17:23] <blackboxsw> Here's the discourse post for reference on recent cloud-init events
[17:23] <Odd_Bloke> #link https://discourse.ubuntu.com/t/cloud-init-status-03-23-2021/21490
[17:23] <blackboxsw> #link https://discourse.ubuntu.com/t/cloud-init-status-03-23-2021/21490
[17:23] <blackboxsw> thanks Odd_Bloke
[17:23] <Odd_Bloke> Haha
[17:23] <Odd_Bloke> Please read it twice.
[17:24] <blackboxsw> and correct any clerical errors
[17:25] <blackboxsw> one topic of interested that hamalq  brought up yesterday was the "feature" of RedHat and CentOS that automatically prefers fqdn  over hostname in #cloud-config per this bug
[17:25] <blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bug/1724414
[17:25] <ubot5> Ubuntu bug 1724414 in cloud-init "rhel distro selects FQDN as hostname" [Low,Won't fix]
[17:26] <blackboxsw> I mentioned we'd bring it up to reflect our opinion on this behavior today after a discussion
[17:28] <blackboxsw> I think the upstream stance on RedHat and CentOS is that this default behavior on RedHat/CentOS has been in play for a long time and changing that default behavior would be asking to cause problems for the majority of users who may rely on this behavior during system launch.
[17:28] <blackboxsw> Odd_Bloke: falcojr did we say in this case we'd prefer a new bug which better describes the desired use-case and how current cloud-init doesn't allow for that use-case?
[17:30] <blackboxsw> that's all the content/discussion I had. I know I needed to get otubo a review today on his resize lvm partition branch https://github.com/canonical/cloud-init/pull/721 as my stale review was blocking that.
[17:31] <Odd_Bloke> We've closed out that bug as Won't Fix; we'd like folks who consider themselves affected by that bug to file a new one which describes their specific problem with the current situation: we can then work to support those requirements.
[18:24] <Odd_Bloke> OK, sounds like there's not much to chat about; thanks to any lurkers. :)
[18:24] <Odd_Bloke> #endmeeting
[18:24] <meetingology> Meeting ended at 18:24:04 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/cloud-init/2021/cloud-init.2021-03-23-17.22.moin.txt
[18:24] <blackboxsw> welcome :) thanks Odd_Bloke
[18:29] <blackboxsw> FWIW published to https://cloud-init.github.io/
[19:42] <hamalq> falcojr: for bug https://bugs.launchpad.net/cloud-init/+bug/1724414
[19:42] <ubot5> Ubuntu bug 1724414 in cloud-init "rhel distro selects FQDN as hostname" [Low,Won't fix]
[19:42] <hamalq> #cloud-config
[19:42] <hamalq> ---
[19:42] <hamalq> enable_shortname: true
[19:42] <hamalq> having an option like this to enable the new default behavior is good solution
[19:42] <hamalq> will not affect old users
[19:42] <hamalq> and will solve the problem
[19:44] <hamalq> for the bug https://bugs.launchpad.net/cloud-init/+bug/1724414
[19:45] <ubot5> Ubuntu bug 1724414 in cloud-init "rhel distro selects FQDN as hostname" [Low,Won't fix]
[19:45] <blackboxsw> hamalq: thanks for heading back on this topic. I think your idea about overrides would make sense.  Can you file a bug https://bugs.launchpad.net/cloud-init/+filebug  which describes the use-case you have a bit more clearly for folks  (why both fqdn and hostname settings are required in your env if you like also to rely on short hostname) I think you just barely missed out office hours
[19:45] <blackboxsw> https://cloud-init.github.io/status-2021-03-23.html#status-2021-03-23
[19:46] <blackboxsw> basically I think we need a better understanding of what cloud-init #cloud-config doesn't do for you in your use-case. as we won't specifically alter the default behavior
[19:46] <blackboxsw> and then with that understand it'd be easier to represent a fix to allow overriding defaults with something like you suggest
[19:47] <hamalq> blackboxsw: will do thanks
[19:48] <blackboxsw> excellent . thanks again
[19:49] <falcojr> do we have an easy way of knowing when our uploads move into proposed? An rmadison flag or something?
[19:58] <Odd_Bloke> falcojr: As in, something that would exit when a particular version appears?  (rmadison does show -proposed if there's anything there, BTW: `rmadison linux-meta`, e.g.)
[20:03] <falcojr> Ahh, that's all I need
[20:03] <falcojr> Didn't know it would return that and figured proposed still contains old stuff that's just not being shown
[20:05] <Odd_Bloke> Aha, right: nope, -proposed is cleaned up as part of the release.  You can see the full history of operations on the cloud-init package at https://launchpad.net/ubuntu/+source/cloud-init/+publishinghistory
[20:05] <Odd_Bloke> s/the release/the release of the package to -updates/
[20:06] <Odd_Bloke> (If you look at the details on a Deleted for non-hirsute, you'll see "moved to -updates" as the deletion reason.)
[20:20] <hamalq> i submitted this bug https://bugs.launchpad.net/cloud-init/+bug/1921004 is it clear enough or should i explain more
[20:20] <ubot5> Ubuntu bug 1921004 in cloud-init "Add an option to use short hostname in RHEL" [Undecided,New]
[20:22] <hamalq> blackboxsw: ^^
[20:24] <Odd_Bloke> falcojr: As requested on https://github.com/canonical/cloud-init/pull/844, I've told you how that regex is wrong. ;)
[20:31] <blackboxsw> thank you hamalq  so your particular concern is an fqdn that is > 64 chars results in an unsettable hostname.
[20:31] <blackboxsw> thank you hamalq  so your particular concern is an fqdn that is > 64 chars results in an unsettable hostname right?
[20:31] <hamalq> yes
[20:32] <hamalq> and sending the hostname in cloud config is not an option in rhel
[20:33] <blackboxsw> I'm wondering if a specific case (which wouldn't involve any additional cloud-config optins is to allow hostname if fqdn > getconf HOST_NAME_MAX`
[20:33] <blackboxsw> since hostname > HOST_NAME_MAX is "broken" anyway
[20:34] <blackboxsw> then one wouldn't have to override defaults or provide new cloud-config options, but cloud-init would just do the right thing
[20:34] <hamalq> that is a solution too ( +1 )
[20:35] <blackboxsw> as in, prefer hostname on rhel if present and fqdn > 64 (or `getconf HOST_NAME_MAX` value)
[20:35] <blackboxsw> anyone providing fqdn > 64 chars is broken anyway right hamalq ?
[20:35] <hamalq> yes that make sense
[20:36] <blackboxsw> ok that's at least fairly easy to confirm and a specific fix for this case that will only affect people who are already "broken"
[20:36] <hamalq> can u update the bug please with that
[20:36] <blackboxsw> hamalq: go for it, we'll grab it in bug triage tomorrow and comment more I bet
[20:37] <blackboxsw> watch for an update on the bug if there are significant concerns about the approach (I don't think Canonical folks will be working on that specifically, but we may have some input to help get a PR like that landed if <someone>  were to propoes it :)
[20:38] <blackboxsw> *propose*
[20:38] <hamalq> i will propose that
[20:41] <hamalq> can u just update the bug that u will triage it so i can talk to the team am working with to give time to work on it
[20:41] <blackboxsw> great to hear thanks. look forward to it. if you haven't signed the CLA you'll need to do that as part of submitting the PR. https://cloudinit.readthedocs.io/en/latest/topics/hacking.html?highlight=cla#submitting-your-first-pull-request
[20:41] <hamalq> blackboxsw: ^^
[20:43] <blackboxsw> hamalq: sorry I didn't quite understand. when we triage the bug someone from upstream cloud-init will comment on this bug one way or another with info about whether the feature is something that makes sense for cloud-init https://bugs.launchpad.net/cloud-init/+bug/1921004. so I'd expected to see the bug set to triaged state with some sort of additional comment or a rejection if it does not appear acceptable
[20:43] <ubot5> Ubuntu bug 1921004 in cloud-init "Add an option to use short hostname in RHEL" [Undecided,New]
[20:44] <blackboxsw> hamalq: can you add results from cloud-init collect-logs to that bug on an affected system. that'll give us the traceback seen on rhel
[20:45] <blackboxsw> hamalq: note that cloud-init logs may contain sensitive information so if you provisioned the machine with userdata that exposes passwords or something you might want to redact that info/
[20:46] <hamalq> i dont have the logs ( and it contain info i cant share) but its easy to reproduce with any FQDN above 64
[20:53] <blackboxsw> +1
[20:53] <falcojr> tbh, I think I'd prefer a separate configuration option. Current behavior is already confusing as it's distro-dependent. Having it be automatic after 64 chars seems to add another layer of "how should this work again???" There are likely people that have hostnames < 64 chars that want the short hostname too. On the other hand, we've recently had
[20:53] <falcojr> somebody request on a non-rhel system to have it be fqdn. If we had a distro-independent setting along the lines of "default_hostname: <short_hostname|fqdn>", that'd be more accessible to everybody and easier to understand
=== vrubiolo1 is now known as vrubiolo
[21:18] <hamalq> if that user send the fqdn only will that work for him
[21:18] <hamalq> ?
[21:19] <hamalq> although different distro having different behavior is not great either
[21:41] <blackboxsw> fair point falcojr yeah, it'd be "magic" that'd only affect rhel in this case. probably better to be explicit