16:29:32 <dustymabe> #startmeeting fedora_coreos_meeting
16:29:32 <zodbot> Meeting started Wed Jul 21 16:29:32 2021 UTC.
16:29:32 <zodbot> This meeting is logged and archived in a public location.
16:29:32 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:29:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:29:32 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:29:39 <dustymabe> #topic roll call
16:29:43 <dustymabe> .hu
16:29:45 <dustymabe> .hi
16:29:46 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:56 <travier> .hello siosm
16:30:57 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:31:22 <miabbott> .hello miabbott
16:31:23 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:31:26 <jbrooks> .hello jasonbrooks
16:31:27 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:31:36 <jlebon> .hello2
16:31:37 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:31:45 <bgilbert> .hi
16:31:46 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:31:48 <darkmuggle> .hello2
16:31:49 <zodbot> darkmuggle: darkmuggle 'None' <me@muggle.dev>
16:32:03 <davdunc> .hello2
16:32:04 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:32:23 <dustymabe> #chair travier miabbott jbrooks jlebon bgilbert darkmuggle davdunc
16:32:23 <zodbot> Current chairs: bgilbert darkmuggle davdunc dustymabe jbrooks jlebon miabbott travier
16:32:27 <skunkerk> .hello sohank2602
16:32:28 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:33:25 <lucab> .hi
16:33:26 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:34:14 <dustymabe> #chair skunkerk lucab
16:34:14 <zodbot> Current chairs: bgilbert darkmuggle davdunc dustymabe jbrooks jlebon lucab miabbott skunkerk travier
16:34:17 <dustymabe> welcome all
16:34:29 <dustymabe> #topic Action items from last meeting
16:35:14 <dustymabe> i think the only real action was for me to update #892 with the notes from the discussion
16:35:37 <dustymabe> #info dustymabe updated #892 with the notes from the video meeting discussion: https://github.com/coreos/fedora-coreos-tracker/issues/892#issuecomment-880907947
16:35:51 <dustymabe> I don't think we had anything else concretely actionable
16:35:58 * dustymabe moves on in a few seconds
16:36:10 <dustymabe> #topic Flock to Fedora 2021 (5th to 7th August 2021) - CFP closes 23rd July
16:36:15 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/894
16:36:20 <dustymabe> i'll touch on this briefly
16:36:36 <dustymabe> travier and I just submitted a talk, jdoss has submitted one and I think jlebon is going to do a deep dive talk
16:36:46 <dustymabe> if anyone else is interested the CFP closes this week
16:36:49 <dustymabe> EOM
16:37:25 <dustymabe> would be really nice to do a half day hackfest for docs, but I don't have the cycles to drive it this time
16:37:35 <dustymabe> if anybody is interested, let me know :)
16:37:43 <travier> (EOM?)
16:37:49 <dustymabe> EOM :)
16:37:55 <dustymabe> oh, "end of message"
16:38:03 <travier> :)
16:38:05 <dustymabe> meaning I'm done, which I think continued to talk
16:38:16 <dustymabe> next topic
16:38:23 <dustymabe> #topic tracker: Fedora 35 changes considerations
16:38:29 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/856
16:38:43 <dustymabe> ok we've got some tickets assigned to people. can we get status updates?
16:38:48 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues?q=is%3Aissue+is%3Aopen+label%3AF35-changes
16:39:30 <dustymabe> darkmuggle: jaimelm: lucab: walters: I think have open items
16:40:40 * dustymabe thinks jaimelm and walters aren't here today - jlebon can you check on walters for this and I'll check on jaimelm?
16:40:51 <jlebon> dustymabe: ack will do
16:41:04 <dustymabe> darkmuggle lucab are here toady I believe
16:41:38 <darkmuggle> I have no updates this week due to other pressing issues. I'll have it for next week.
16:41:44 <dustymabe> darkmuggle++
16:41:44 <zodbot> dustymabe: Karma for darkmuggle changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:42:04 <dustymabe> I think lucab made progress - but not sure if the work he posted was all that was needed or just the tip of the iceberg
16:42:10 <lucab> I did a round of updates for new openssl crates in all our projects using it. The status is tracked in the ticket. Bootupd needs to get the CI fixed first, afterburn and coreos-installer will be fine upon the next release, zincati and rpm-ostree are already fine.
16:42:39 <dustymabe> lucab: is that the totality of the changes that are needed? or are those just some of it and there are a lot more?
16:42:49 <dustymabe> i.e. when the bootupd change merges can we close it out?
16:43:22 <lucab> That's all I can think of. When they are all released and packaged, we can close it.
16:43:41 <dustymabe> nice - wasn't sure if there were "non rust" things we needed to consider
16:44:14 <dustymabe> #info lucab is tracking all changes for openssl and we should be able to close out #876 soon
16:44:29 <dustymabe> ok I think that's all for this topic for this week but...
16:44:40 <lucab> golang things are not concerned, and the only C things are ostree and rpm-ostree which I think are already fine
16:44:58 <dustymabe> #action dustymabe to re-index and look for newly submitted change proposals for f35 that we need to consider
16:45:12 <dustymabe> i'm sure there are some new ones that weren't on our original list so I'll do ^^ for next week
16:45:35 * dustymabe moves on to next topic soon
16:45:55 <dustymabe> #topic policy: setting single node defaults that don't enhance kubernetes
16:45:58 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/880
16:46:15 <dustymabe> ok I feel like we're beating a dead horse here, but I want to try to close this topic off
16:46:27 <dustymabe> from my temperature taking I think we are at something like:
16:46:32 <dustymabe> #propsed We implement the single node optimized defaults now for "new installs". We add documentation for k8s distributors. Before we automigrate existing nodes in the future we'll revisit the feature flags proposal.
16:46:35 <dustymabe> sigh
16:46:45 <dustymabe> #proposed We implement the single node optimized defaults now for "new installs". We add documentation for k8s distributors. Before we automigrate existing nodes in the future we'll revisit the feature flags proposal.
16:47:29 <dustymabe> does that accurately reflect the summation of our discussions on the topic?
16:47:29 <bgilbert> it's a breaking change, so we can't do it now.  we need a deprecation period.
16:47:36 <jlebon> ack, assuming the heads up to k8s distributors has sufficient time
16:48:16 <dustymabe> right, but the amount of time required should be much smaller because it's only for new nodes, right?
16:48:31 <dustymabe> still will require the distributors to implement changes
16:48:32 <travier> This still needs 3 months at least
16:48:59 <travier> I think we should follow the same process we did for cgroups v2
16:49:17 <dustymabe> ok fair
16:49:28 <bgilbert> dustymabe: no, there's nothing special about new nodes
16:49:39 <bgilbert> we want clusters to autoscale using the current release images
16:49:57 <jlebon> personally, i think we can just talk to OKD and Typhoon to make sure they're aware and land on a reasonable time
16:50:13 <travier> First write docs to keep existing behavior, then warn about the change, then wait X (3 minimum) months
16:50:39 <jlebon> 3 months feels like overkill to me if both of those communities are ready to go, but not against either
16:50:51 <dustymabe> bgilbert: right, I'm just thinking figuring out how to implement the change for new nodes will be easier than the distributors trying to figure out how to update configuration on their existing nodes
16:50:55 <bgilbert> jlebon: I think we should assume we have users who don't talk to us :-)
16:51:10 <dustymabe> #proposed We implement the single node optimized defaults now for "new installs" with an appropriate amount of time allowed for kubernetes distributors to update their provisioning. We add documentation for k8s distributors. Before we automigrate existing nodes in the future we'll revisit the feature flags proposal.
16:51:39 <dustymabe> better ^^ ?
16:51:53 <bgilbert> wording quibble: s/distributors/distributors and users/
16:52:11 <bgilbert> (i.e., include DIYers in our thinking)
16:52:26 <dustymabe> yeah let me also update to not include the word "now"
16:53:12 <dustymabe> #proposed After an appropriate period of notice we implement the single node optimized defaults for "new installs". We add documentation for k8s distributors. Before we automigrate existing nodes in the future we'll revisit the feature flags proposal.
16:53:23 <dustymabe> better?
16:53:33 <jlebon> ack
16:54:04 * dustymabe ack
16:54:29 <bgilbert> ack, though the last sentence is a bit odd
16:55:01 <bgilbert> are we planning to automigrate?  it's just service enablement in this case
16:55:26 <dustymabe> yeah, my thinking there is that before we automigrate existing nodes (if we ever do) we probably would want to re-visit the feature flags proposal and consider it as a way to help delivery
16:55:47 <dustymabe> I can strike that sentence if desired
16:55:54 <bgilbert> "If we automigrate existing nodes in the future, we'll revisit the feature flags proposal first"?
16:56:02 <dustymabe> sure
16:56:16 <miabbott> don't forget the `distributors and users` change
16:56:21 <travier> (making this for new installs only will require a barrier release)
16:56:52 <dustymabe> miabbott: I removed the first "distributors" word in the proposed, which I think is what BG was talking about
16:57:06 <dustymabe> #proposed After an appropriate period of notice we implement the single node optimized defaults for "new installs". We add documentation for k8s distributors. If we automigrate existing nodes in the future, we'll revisit the feature flags proposal first.
16:57:21 <bgilbert> dustymabe: yeah, but doesn't hurt to add it anyway
16:57:26 <dustymabe> bgilbert: +1
16:57:39 <dustymabe> #proposed After an appropriate period of notice we implement the single node optimized defaults for "new installs". We add documentation for k8s distributors and users. If we automigrate existing nodes in the future, we'll revisit the feature flags proposal first.
16:57:42 <dustymabe> travier: why?
16:58:04 <travier> How do you not enable a service for existing installs?
16:58:04 <dustymabe> ahh, well - "may" require a barrier release
16:58:19 <dustymabe> depends on the change I guess
16:58:32 <bgilbert> travier: presets?
16:58:55 <travier> they are applied to existing system with rpm-ostree if I'm not mistaken
16:59:18 <dustymabe> travier: yes, if we need barrier releases to pull this off, then we'll put them in place
16:59:28 <dustymabe> call for ack/nack on current proposed?
16:59:38 <travier> this is not a counter point, just a notice
16:59:42 <travier> ack
17:00:01 <bgilbert> ack
17:00:35 <jlebon> ack
17:00:51 * dustymabe ack
17:00:54 <dustymabe> any others?
17:00:59 <miabbott> ack
17:01:08 <skunkerk> ack
17:01:25 <dustymabe> #agreed After an appropriate period of notice we implement the single node optimized defaults for "new installs". We add documentation for k8s distributors and users. If we automigrate existing nodes in the future, we'll revisit the feature flags proposal first.
17:01:26 <walters> semi-ack, didn't follow all the details but the overall seems sane
17:01:35 <dustymabe> thanks all, thanks walters
17:01:45 <dustymabe> #topic New Package Request: oci-seccomp-bpf-hook
17:01:50 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/887
17:03:04 <walters> i think package layering seems fine for this
17:03:43 <dustymabe> yeah, also is this OKD specific?
17:04:01 <dustymabe> they do some fancy stuff in their build system to configure FCOS so maybe could be done there
17:04:05 <jlebon> it's useful for anyone who wants to use seccomp for their containers
17:04:30 <jlebon> but yeah, i don't think it makes sense in the host by default IMO
17:04:30 <lucab> I do share jlebon's feedbacks there: 1) no need to build the profile on each node, it can be done offline 2) they probably want OKD/OCP extensions to automate an operator there
17:04:33 <dustymabe> I see, so the use specifically for them was the operator, but this is generally usefull too
17:05:04 <travier> llvm-libs > This makes it hard to include :/
17:06:11 <walters> hmm I guess it depends on whether one would *always* trace the container and only periodically regenerate policy or whether there's a separate "training phase" e.g. on a dedicated node
17:06:28 <dustymabe> #proposed Given the required dependencies and the specifics of the use case we thing this is a good candidate for package layering/extensions and not for inclusion in the base OSTree. The seccomp profiles can also be generated offline and included to remove the need to have it installed at all?
17:06:39 <dustymabe> is that last sentence in the #proposed true?
17:06:42 <dustymabe> lucab: ^^
17:06:52 <walters> Yeah I'm pretty sure
17:07:08 <travier> +1
17:07:09 <lucab> that's my understanding
17:07:12 <dustymabe> maybe I should say "and included via Ignition"
17:07:15 <jlebon> yup my uinderstanding as well
17:07:26 <jlebon> +1
17:07:31 <dustymabe> #proposed Given the required dependencies and the specifics of the use case we thing this is a good candidate for package layering/extensions and not for inclusion in the base OSTree. The seccomp profiles can also be generated offline and included via Ignition, which will remove the need to have it installed at all.
17:07:51 <bgilbert> *think
17:08:02 <dustymabe> #undo
17:08:02 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f4737fc5650>
17:08:11 <jlebon> walters: i would think you'd train it on known workloads. presumably the idea is that in prod you already know what it needs and everything else should be blocked
17:08:20 <dustymabe> #proposed Given the required dependencies and the specifics of the use case we think this is a good candidate for package layering/extensions and not for inclusion in the base OSTree. The seccomp profiles can also be generated offline and included via Ignition, which will remove the need to have it installed at all.
17:08:21 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/887
17:08:40 <skunkerk> +1
17:09:03 <jlebon> ack
17:09:08 * dustymabe ack
17:09:18 <travier> +1
17:09:30 <miabbott> ack
17:09:31 <bgilbert> +1
17:09:46 <dustymabe> #agreed Given the required dependencies and the specifics of the use case we think this is a good candidate for package layering/extensions and not for inclusion in the base OSTree. The seccomp profiles can also be generated offline and included via Ignition, which will remove the need to have it installed at all.
17:10:00 <dustymabe> #topic coordinating default hostname with other Fedora editions
17:10:03 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/902
17:10:17 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/902
17:10:52 <jlebon> maybe link it one more time just in case :)
17:10:56 <dustymabe> ok I added this one. basically do we want to keep our "`localhost` is default hostname" forever and if yes should we try to advocate for making a change at a higher leve
17:11:16 <dustymabe> jlebon: :) - my client is playing tricks on me today
17:11:45 <jlebon> i think we should advocate for a change, but match whatever we decide in the end
17:12:04 <jlebon> "we decide" -> Fedora as a whole
17:12:09 <dustymabe> jlebon: I guess we can break this out into two topics
17:12:35 <dustymabe> 1. should we advocate for the change at a higher level
17:12:37 <dustymabe> and
17:12:54 <dustymabe> 2. if the change at a higher level is rejected, do we continue to carry the change or do we fall in line?
17:13:33 <dustymabe> where "we" == FCOS
17:13:34 <jlebon> dustymabe: yeah makes sense
17:13:56 <travier> On which other editions do you want that to happen?
17:14:22 <travier> Because I don't understand why other edition would want to use another default
17:14:26 <travier> editions*
17:14:30 <dustymabe> travier: I'm thinking the arguments around this topic originally were " workstation needs it this way"
17:14:30 <cyberpear> what's the ideal state?  'fedora' as a default hostname has seemed strange to me ever since they made the change
17:14:49 <dustymabe> because of avahi or mDNS or something
17:15:08 <jlebon> i think it'd be Server, IoT, and CoreOS
17:15:10 <dustymabe> so the thoughts there are - if that's true, let's try to make that change only apply to workstation
17:15:20 <cyberpear> was there a change proposal for this one when it hit the other fedora editions?
17:15:22 <bgilbert> and also DNS driven by DHCP client ID
17:15:22 <dustymabe> s/workstation/workstation like/
17:15:54 <dustymabe> cyberpear: I don't think so. I think it just landed in f33
17:17:00 <travier> I can not find a change proposal
17:17:09 <travier> which is not great
17:17:09 <jlebon> travier: there wasn't one
17:17:18 <jlebon> https://bugzilla.redhat.com/show_bug.cgi?id=1892235#c13
17:17:56 <dustymabe> so.. we could take this topic to a subtopic and ask "what are the arguments for keeping it at `localhost`"
17:18:10 <dustymabe> the reasoning I can think of can be poked holes in
17:18:23 <dustymabe> 1. peoples scripts assume localhost == unconfigured
17:18:37 <dustymabe> 2. it's expected when there is no outher source for hostname
17:18:53 <dustymabe> s/expected/generally expected/
17:19:05 <dustymabe> but those aren't super compelling
17:19:22 <dustymabe> i'd be interested in other more compelling reasons
17:20:24 <dustymabe> marco...
17:21:13 <dustymabe> moving on..
17:21:34 <walters> i think the argument is things implicitly depended on it and let's not break them?
17:21:43 <jlebon> i don't think it's just scripts which assume localhost == unconfigured.  lucab pointed out it's a reserved identifier
17:22:45 <dustymabe> so is that an argument for more compelling arguments?
17:22:47 <jlebon> https://en.wikipedia.org/wiki/Localhost#IETF_standards
17:23:07 <dustymabe> ok I was going with: #proposed we start a discussion with FESCO about potentially updating the default hostname to be localhost for server like editions. If that is rejected we fall in line and migrate to `fedora` for the default hostname like the rest of the Fedora editions.
17:23:37 <dustymabe> but now maybe
17:23:38 <darkmuggle> point 1 is a compelling reason. That's 2+ decades of expectation to to change. And there are people who work across multiple distros.
17:23:40 <dustymabe> #proposed we start a discussion with FESCO about potentially updating the default hostname to be localhost for server like editions. If that is rejected then we re-visit if we want to carry the delta just in FCOS or not.
17:24:01 <travier> +1 to discuss and revisit
17:24:06 <darkmuggle> +1
17:24:11 <walters> sgtm
17:24:12 <jlebon> +1
17:24:15 * dustymabe ack
17:24:28 <cyberpear> +1
17:24:34 <dustymabe> #agreed we start a discussion with FESCO about potentially updating the default hostname to be localhost for server like editions. If that is rejected then we re-visit if we want to carry the delta just in FCOS or not.
17:24:38 <travier> I think we should keep an empty localhost default
17:24:55 <dustymabe> #topic open floor
17:24:56 <bgilbert> +1
17:24:56 <travier> (that's for later)
17:24:57 <jlebon> i wonder whether this would've gone through if it were a change proposal
17:25:15 <dustymabe> jlebon: yeah, unfortunately the "inertia" is against us now
17:25:24 <jlebon> yeah definitely :(
17:25:40 <dustymabe> hmm inertia would be a cool name for a project
17:25:58 <bgilbert> dustymabe: once you get some project to use it, they'd never change it
17:26:02 <bgilbert> #info we're working on updates for CVE-2021-33909 and CVE-2021-33910 (kernel and systemd)
17:26:03 <dustymabe> anyone with anything for open floor - there was anothe topic on the docket but jaimelm wasn't here so we'll wait
17:26:08 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/904
17:26:09 <dustymabe> bgilbert: ha
17:26:30 <dustymabe> bgilbert: thanks for that FYI. indeed
17:26:32 <jlebon> hehe
17:26:44 <bgilbert> current plan is a 24-hour rollout for next and testing starting in 35 minutes, and a 24 or 36 hour rollout for stable starting tomorrow.
17:26:53 <jlebon> bgilbert++
17:26:53 <zodbot> jlebon: Karma for bgilbert changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:58 <dustymabe> bgilbert: should we send a status post on that topic or just let it roll out?
17:27:10 <dustymabe> bgilbert++
17:27:13 <travier> bgilbert++
17:27:33 <bgilbert> #info we're deploying a one-off 5.12 kernel build that hasn't gone through Bodhi and includes unrelated changes, so please test the upcoming next and testing releases
17:28:09 * dustymabe will convert all my existing nodes
17:28:16 <bgilbert> ^ that's because Fedora is in the middle of switching to 5.13.  bad timing :-(
17:28:18 <travier> Hum, that sound like something we need to announce :/
17:28:44 <bgilbert> travier: yeah, maybe.  what do folks think?
17:29:01 <dustymabe> i'm cool with a status post on the $topic
17:29:08 <travier> it's the "unrelated" changes part that makes me think that
17:29:17 <bgilbert> right
17:29:29 <travier> not the security update per se
17:29:37 <bgilbert> yeah, the security fix is two lines
17:30:04 <bgilbert> other opinions?  jlebon, lucab?
17:30:13 <jlebon> was the 5.12 revision on top of which the patch was applied released through bodhi?
17:30:32 <jlebon> right, i guess not. that's the unrelated changes bit
17:31:05 <dustymabe> yeah we bumped minor version number too, but not major
17:31:31 <jlebon> status post wfm
17:31:57 <bgilbert> the last Bodhi 5.12 was 5.12.17; this is 19
17:32:32 <dustymabe> the `stable` release kernel is kernel-5.12.12-300.fc34.x86_64
17:32:35 <dustymabe> current stable
17:32:59 <lucab> "testing == YOLO"
17:32:59 <jlebon> and testing was 5.12.14
17:33:26 <jlebon> so we're going up 5 point releases in testing, but 7 in stable
17:33:52 <travier> yeah, that's a bit of jump for a stable release without much field testing
17:34:03 <bgilbert> yeah, I'll put together an email
17:34:18 <dustymabe> we *could* just advance our promotion schedule and bump stable to match our currently rolling out `testing`
17:34:57 <dustymabe> not sure if it's worth it, though
17:35:09 <dustymabe> at least that exact content set would have run through some users
17:35:09 <bgilbert> security fix + unrelated changes is not a great pattern
17:35:51 <bgilbert> I'd lean toward taking the extra reboot
17:35:55 * dustymabe notes the time
17:35:57 <jlebon> i guess ideally we would've had two separate builds for testing/next and stable, but that's a lot of work for maintainers
17:36:27 <jlebon> my vote is to just roll with the current plan and email status
17:36:34 <dustymabe> WFM
17:36:47 <bgilbert> +1
17:36:52 <travier> +1
17:36:56 <dustymabe> will end the meeting soon
17:37:15 <dustymabe> #endmeeting