2024-07-10 16:30:04 <@apiaseck:matrix.org> !startmeeting fedora_coreos_meeting
2024-07-10 16:30:07 <@meetbot:fedora.im> Meeting started at 2024-07-10 16:30:04 UTC
2024-07-10 16:30:07 <@meetbot:fedora.im> The Meeting name is 'fedora_coreos_meeting'
2024-07-10 16:30:14 <@apiaseck:matrix.org> !topic roll call
2024-07-10 16:30:16 <@jbtrystram:matrix.org> !hi
2024-07-10 16:30:18 <@zodbot:fedora.im> Jean-Baptiste Trystram (jbtrystram) - he / him / his
2024-07-10 16:30:51 <@marmijo:fedora.im> !hi
2024-07-10 16:30:52 <@zodbot:fedora.im> Michael Armijo (marmijo)
2024-07-10 16:31:02 <@ravanelli:matrix.org> !hi ravanelli
2024-07-10 16:31:03 <@zodbot:fedora.im> Renata Ravanelli (ravanelli)
2024-07-10 16:31:07 <@siosm:matrix.org> !hi
2024-07-10 16:31:09 <@zodbot:fedora.im> Timothée Ravier (siosm) - he / him / his
2024-07-10 16:31:18 <@jlebon:fedora.im> !hi
2024-07-10 16:31:19 <@zodbot:fedora.im> None (jlebon)
2024-07-10 16:31:24 <@hricky:fedora.im> !hi
2024-07-10 16:31:25 <@zodbot:fedora.im> Hristo Marinov (hricky) - he / him / his
2024-07-10 16:31:53 <@jlebon:fedora.im> apiaseck: i just realized that i didn't do all the housekeeping steps for the previous meeting
2024-07-10 16:32:05 <@apiaseck:matrix.org> I can look into that later on.
2024-07-10 16:32:32 <@jlebon:fedora.im> it's ok. it's not worth posting the summary at this point i think
2024-07-10 16:33:33 <@jlebon:fedora.im> i was checking if any meeting issues should be untagged. there's just the change considerations one from last week, which i've dropped
2024-07-10 16:33:49 <@apiaseck:matrix.org> Since it's a nice bunch of us here, let's start already.
2024-07-10 16:34:02 <@apiaseck:matrix.org> !topic Action items from last meeting
2024-07-10 16:34:04 <@jlebon:fedora.im> marmijo: once you get around to updating that list, if there are any new ones, you can re-add the label
2024-07-10 16:34:05 <@siosm:matrix.org> Jonathan Lebon: anything we should tackle first?
2024-07-10 16:34:21 <@marmijo:fedora.im> Jonathan Lebon: sure thing. I'll update the list today
2024-07-10 16:34:24 <@ydesouza:fedora.im> !hi
2024-07-10 16:34:25 <@jlebon:fedora.im> travier:  i think https://github.com/coreos/fedora-coreos-tracker/issues/1758 is the most pressing
2024-07-10 16:34:25 <@zodbot:fedora.im> Yasmin Valim de Souza (ydesouza)
2024-07-10 16:34:55 <@jlebon:fedora.im> and then https://github.com/coreos/fedora-coreos-tracker/issues/1745 would be good to discuss too
2024-07-10 16:35:38 <@apiaseck:matrix.org> I can't see any action items, so let's move on to the first proposed by Jonathan Lebon 
2024-07-10 16:36:08 <@apiaseck:matrix.org> !topic No serial console login after update to 40.20240616.3.0
2024-07-10 16:36:15 <@apiaseck:matrix.org> !link https://github.com/coreos/fedora-coreos-tracker/issues/1758
2024-07-10 16:37:16 <@apiaseck:matrix.org> Jonathan Lebon, travier. Would any of you would like to introduce this one?
2024-07-10 16:37:23 <@jlebon:fedora.im> sure
2024-07-10 16:37:26 <@apiaseck:matrix.org> Jonathan Lebon, travier. Would any of you like to introduce this one?
2024-07-10 16:37:32 <@dustymabe:matrix.org> !hi
2024-07-10 16:37:33 <@zodbot:fedora.im> Dusty Mabe (dustymabe) - he / him / his
2024-07-10 16:37:57 <@aaradhak:matrix.org> !hi aaradhak
2024-07-10 16:37:58 <@zodbot:fedora.im> Aashish Radhakrishnan (aaradhak)
2024-07-10 16:38:38 <@jlebon:fedora.im> in a recent release we did, an selinux-policy update broke systemd-getty-generator, which means that the serial-getty@.service isn't instantiated for the available serial ports. concretely: users can't log into the serial console anymore
2024-07-10 16:39:02 <@jbrooks:matrix.org> !hi jasonbrooks
2024-07-10 16:39:04 <@zodbot:fedora.im> Jason Brooks (jasonbrooks) - he / him / his
2024-07-10 16:39:15 <@jlebon:fedora.im> now, first, it's pretty embarrassing this slipped by. we clearly need a test for this
2024-07-10 16:39:27 <@jlebon:fedora.im> so that's number 1
2024-07-10 16:40:06 <@siosm:matrix.org> No idea how difficult writing a test would be. If it's "just" checking the systemd unit status then that should be fairly easy
2024-07-10 16:40:17 <@jlebon:fedora.im> number 2 is how to handle this
2024-07-10 16:40:17 <@jlebon:fedora.im> currently, i've pinned selinux-policy to a working version in testing-devel so it'll be in the next testing and next
2024-07-10 16:40:17 <@jlebon:fedora.im> the bug is not fixed yet.
2024-07-10 16:40:33 <@jlebon:fedora.im> the question is whether to fast-track the pin to stable too
2024-07-10 16:40:39 <@jlebon:fedora.im> travier: i think we can just check the console output
2024-07-10 16:40:49 <@jlebon:fedora.im> we do this already for the auto-login test in kola testiso
2024-07-10 16:41:00 <@siosm:matrix.org> ah, indeed, but that would be in kola then?
2024-07-10 16:41:36 <@jlebon:fedora.im> yeah... it'd need some design if we want to try to make it an external test. but clearly possible
2024-07-10 16:41:52 <@jlebon:fedora.im> worth noting that there are multiple ways to work around this
2024-07-10 16:42:22 <@jlebon:fedora.im> one is to boot with `enforcing=0`, another is to manually override selinux-policy, another is to manually enable serial-getty@PORT.service
2024-07-10 16:42:35 <@dustymabe:matrix.org> Has this reached stable yet? Or is it just in testing
2024-07-10 16:42:41 <@jlebon:fedora.im> it has
2024-07-10 16:43:09 <@siosm:matrix.org> Made https://github.com/coreos/coreos-assembler/issues/3832
2024-07-10 16:43:34 <@dustymabe:matrix.org> Part of me wants it fixed sooner, but either way it will be fixed in a few weeks?
2024-07-10 16:43:40 <@jlebon:fedora.im> so one argument is to not risk it and not fast-track; people that need the serial console can use one of the workarounds
2024-07-10 16:44:28 <@jlebon:fedora.im> another argument is that serial console is pretty basic functionality, and it may be the only way a user has to get into the system (or may not have easy access to the GRUB menu to select the rollback/edit kargs)
2024-07-10 16:44:34 <@siosm:matrix.org> The thing is, usually, when you need console access is when the rest doesn't work so you can't really apply those workarounds
2024-07-10 16:45:14 <@jbtrystram:matrix.org> I feel we had a lot of issues with selinux-policy recently. Could we ask them to gate their releases on the kola tests ? They are in boghi already 
2024-07-10 16:45:46 <@jlebon:fedora.im> overall, i lean towards fast-tracking. worth noting that the pinned version shipped in stable before
2024-07-10 16:45:48 <@jbtrystram:matrix.org> I feel we had a lot of issues with selinux-policy recently. Could we ask them to gate their releases on the kola tests ? They are in bodhi already 
2024-07-10 16:46:08 <@jlebon:fedora.im> jbtrystram: that's the long-term goal, but it's part of a much larger effort
2024-07-10 16:46:33 <@jbtrystram:matrix.org> +1 to fast track and writing up some documentation for affected users
2024-07-10 16:46:36 <@marmijo:fedora.im> I'd agree with fast-tracking as well, especially if there could be situations where users cant apply the workaround
2024-07-10 16:46:53 <@marmijo:fedora.im> I'd agree with fast-tracking as well, especially if there could be situations where users cant apply the workarounds
2024-07-10 16:47:32 <@apiaseck:matrix.org> Let's propose, and have the voting on the above, shall we ?
2024-07-10 16:47:42 <@jbtrystram:matrix.org> Jonathan Lebon: I know but I'm just thinking it's worth reaching out and say "maybe please look closely at these tests because we've had a lot of issues?"
2024-07-10 16:48:01 <@jbtrystram:matrix.org> (^ about bodhi tests)
2024-07-10 16:48:20 <@jlebon:fedora.im> jbtrystram: ahhh gotcha. yeah, possibly.
2024-07-10 16:48:53 <@apiaseck:matrix.org> initial proposed: We will fast track and write up documentation for affected users regarding the `no serial console login`
2024-07-10 16:49:29 <@jbtrystram:matrix.org> Maybe they are not even aware they're there. I reached out to the kdump folks with the same message, maybe nothing will come out of it, but it is worth trying 
2024-07-10 16:49:52 <@siosm:matrix.org> +1 for proposed
2024-07-10 16:49:55 <@jbtrystram:matrix.org> +1
2024-07-10 16:50:06 <@ravanelli:matrix.org> +1
2024-07-10 16:50:08 <@aaradhak:matrix.org> +1
2024-07-10 16:50:15 <@marmijo:fedora.im> +1
2024-07-10 16:50:27 <@jlebon:fedora.im> +1
2024-07-10 16:50:27 <@jlebon:fedora.im> "We will fast-track the selinux-policy rollback to stable and ..."
2024-07-10 16:51:13 <@apiaseck:matrix.org> proposed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console login
2024-07-10 16:51:35 <@apiaseck:matrix.org> !proposed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console login
2024-07-10 16:52:14 <@siosm:matrix.org> +1
2024-07-10 16:52:23 <@jlebon:fedora.im> i think we have enough for an agreed :)
2024-07-10 16:52:34 <@apiaseck:matrix.org> Not sure if there should be an `!` before proposed here, but I will amend that in the summary.
2024-07-10 16:53:05 <@apiaseck:matrix.org> agreed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
2024-07-10 16:53:16 <@apiaseck:matrix.org> !agreed: We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
2024-07-10 16:53:53 <@jbtrystram:matrix.org> remove the : :) 
2024-07-10 16:54:02 <@jbtrystram:matrix.org> remove the `:` :) 
2024-07-10 16:54:07 <@apiaseck:matrix.org> !agreed We will fast-track the selinux-policy rollback to stable and write up documentation for affected users regarding the no serial console logi
2024-07-10 16:54:17 <@apiaseck:matrix.org> ++ jbtrystram 
2024-07-10 16:54:32 <@apiaseck:matrix.org>  jbtrystram ++
2024-07-10 16:54:34 <@zodbot:fedora.im> c4rt0 gave a cookie to jbtrystram. They now have 1 cookie, 1 of which was obtained in the Fedora 40 release cycle
2024-07-10 16:54:37 <@apiaseck:matrix.org> Can we move on to the second proposed topic: `Different partition layout` or is there anything else to discuss here?
2024-07-10 16:54:59 <@jlebon:fedora.im> i think since dustymabe and travier are finally both there, let's do the firewalld one
2024-07-10 16:55:43 <@apiaseck:matrix.org> I can't see any objections :) 
2024-07-10 16:55:49 <@apiaseck:matrix.org> !topic New Package Request: firewalld
2024-07-10 16:55:50 <@dustymabe:matrix.org> 😀 - might not be able to make the best argument. Currently holding a baby, but let’s proceed 
2024-07-10 16:55:58 <@apiaseck:matrix.org> !link https://github.com/coreos/fedora-coreos-tracker/issues/1747
2024-07-10 16:56:52 <@apiaseck:matrix.org> Anyone feels like introducing this one?
2024-07-10 16:57:14 <@jlebon:fedora.im> i nominate travier :)
2024-07-10 16:57:50 <@apiaseck:matrix.org> travier: the floor is yours :) 
2024-07-10 16:59:39 <@siosm:matrix.org> :)
2024-07-10 17:00:05 <@siosm:matrix.org> Some folks want to include firewalld by default in Fedora CoreOS
2024-07-10 17:00:47 <@siosm:matrix.org> The summary of the discussion is that it should work well as a container
2024-07-10 17:01:11 <@siosm:matrix.org> It also pulls in Python (which would be the first one to pull it)
2024-07-10 17:01:16 <@hricky:fedora.im> I tried the container and it works.
2024-07-10 17:02:02 <@siosm:matrix.org> The main advantage of adding firewalld would be that we would be "closer" to other editions
2024-07-10 17:02:12 <@siosm:matrix.org> but I don't know if server or cloud includes it by default
2024-07-10 17:02:30 <@jbtrystram:matrix.org> server does I think
2024-07-10 17:02:32 <@siosm:matrix.org> That's for the non personal points
2024-07-10 17:02:40 <@dustymabe:matrix.org> i'm pretty sure server does, not sure about cloud (the arguments for firewall in the cloud are a little weaker IMO) 
2024-07-10 17:03:46 <@dustymabe:matrix.org> I think the main advantage of adding it would be that something that seems like basic functionality would be included by default. The way I look at it this is similar to using networkmanager to manage network versus ip commands - firewalld versus iptables/nftables seems similar to me.
2024-07-10 17:04:08 <@siosm:matrix.org> From my personal perspective, it's not worth it. It's easily layered, it works as a container, most people are not going to use it as they will use either podman/docker network native isolation or cloud firewalls.
2024-07-10 17:04:49 <@siosm:matrix.org> And it brings Python. Bringing python for udev rules and better cloud support, I can get behind. Not for firewalld.
2024-07-10 17:05:13 <@siosm:matrix.org> We would likely not enable it by default either as that would break users (and it's super slow)
2024-07-10 17:05:20 <@jlebon:fedora.im> I also don't personally think it's worth it out of the box for our intended use case.
2024-07-10 17:05:29 <@dustymabe:matrix.org> I think the point of us having the prior discussion (on python) was to exclude it from this discussion 
2024-07-10 17:07:04 <@siosm:matrix.org> it's not a blocking point, but it's still a point to consider
2024-07-10 17:08:15 <@jlebon:fedora.im> dustymabe: minor nuance: the point for me of that discussion was to treat it like any other package. also of course it'll never be just python, it'll be python + libraries of whatever application we're considering
2024-07-10 17:08:57 <@siosm:matrix.org> From my personal usage, podman networking has completely removed the need for a firewall on my systems. I used to have very strict rules in place, with custom nftables scripts, etc.
2024-07-10 17:09:01 <@dustymabe:matrix.org> Another thing that makes me favor including it is our claim that our OS is secure.. I know we wouldn't want to enable firewalld by default (at least initially) but we may consider it in the future in some cases
2024-07-10 17:09:25 <@siosm:matrix.org> I no longer do, I just run containers with no ports exposed or with the ports needed published on a podman network
2024-07-10 17:09:37 <@dustymabe:matrix.org> travier: when you say `podman networking` what do you mean exactly? 
2024-07-10 17:10:09 <@siosm:matrix.org> If you run a container with podman it runs it in a network that is not accessible from the internet
2024-07-10 17:10:22 <@siosm:matrix.org> you need to explicitly publish ports
2024-07-10 17:10:27 <@siosm:matrix.org> (same with docker)
2024-07-10 17:11:00 <@dustymabe:matrix.org> right, it's juts in a different network namespace (unless you use the host's) 
2024-07-10 17:11:02 <@siosm:matrix.org> the super common use case of firewall rules is to say which ports are accessible from the network
2024-07-10 17:11:22 <@siosm:matrix.org> you get that "for free" with containers
2024-07-10 17:11:49 <@siosm:matrix.org> sure it's not the exact same thing, you can still run in the host namespace, run rootless containers and publish, etc.
2024-07-10 17:13:30 <@dustymabe:matrix.org> 
2024-07-10 17:13:30 <@dustymabe:matrix.org> that page could then go on to explain how to layer in firewalld and use it OR use it from a container 
2024-07-10 17:13:30 <@dustymabe:matrix.org> ok so to counteract the argument I made before about the host being secure I think we should have a docs page that discusses all of this (i.e. exactly which ports our systems listen on by default (ssh being one) and why we think there really isn't the need for a firewall because of container networking works) 
2024-07-10 17:13:48 <@jlebon:fedora.im> maybe it would help if we discussed the firewalld use cases. does did you have in mind dustymabe ?
2024-07-10 17:13:55 <@jlebon:fedora.im> maybe it would help if we discussed the firewalld use cases. what did you have in mind dustymabe ?
2024-07-10 17:14:13 <@jlebon:fedora.im> yeah, definitely worth documenting
2024-07-10 17:14:39 <@dustymabe:matrix.org> maybe from what travier said it covers most everything 
2024-07-10 17:14:51 <@jlebon:fedora.im> one useful thing i can imagine is restricting ip ranges for sshd
2024-07-10 17:15:07 <@dustymabe:matrix.org> oh yeah. I acutally do that on my home router
2024-07-10 17:15:10 <@jlebon:fedora.im> we commonly do that in the cloud (but using the cloud tools of course)
2024-07-10 17:16:00 <@jlebon:fedora.im> sshd is really the only thing we have by default you may want to add firewall rules for
2024-07-10 17:16:22 <@dustymabe:matrix.org> 
2024-07-10 17:16:22 <@dustymabe:matrix.org> ```
2024-07-10 17:16:22 <@dustymabe:matrix.org> ```
2024-07-10 17:16:50 <@dustymabe:matrix.org> ```
2024-07-10 17:16:50 <@dustymabe:matrix.org> ```
2024-07-10 17:16:50 <@dustymabe:matrix.org> 
2024-07-10 17:16:50 <@dustymabe:matrix.org>       rule family="ipv4" source address="x.x.x.x/32" service name="ssh" log prefix="dustymabecomssh " level="info" limit value="1/m" accept
2024-07-10 17:16:50 <@dustymabe:matrix.org> rich rules:    
2024-07-10 17:17:10 <@dustymabe:matrix.org> limits by source address and also limits to 1 try per minute 
2024-07-10 17:17:51 <@dustymabe:matrix.org> but I don't know if that's a compelling enough reason
2024-07-10 17:18:59 <@siosm:matrix.org> What I do now is I put my sshd daemon behind a wireguard interface, which has other trade offs (I can login from anywhere but I need the wireguard keys)
2024-07-10 17:18:59 <@dustymabe:matrix.org> TBH I'm suprised systemd hasn't baked this functionality in yet (systemd-firewalld) :) 
2024-07-10 17:19:39 <@jlebon:fedora.im> dustymabe: now you're giving people ideas :)
2024-07-10 17:19:45 <@dustymabe:matrix.org> travier: yeah I do something similar with tailscale, but have this one path in as a fallback in case tailscale isn't working 
2024-07-10 17:20:02 <@jbtrystram:matrix.org> dustymabe: i am curious how do you decide on the source address range ?
2024-07-10 17:20:21 <@dustymabe:matrix.org> jbtrystram: it's just a specific IP from another intstance I own
2024-07-10 17:20:32 <@jlebon:fedora.im> if possible, i'd like to bring up something from a discussion with Hristo Marinov before we close
2024-07-10 17:21:30 <@jlebon:fedora.im> proposed: currently, we are not considering adding firewalld by default. we will however add documention detailing every port open by default, and instructions on how to add firewalld to the host.
2024-07-10 17:21:30 <@jlebon:fedora.im> let me write up a proposed to accelerate things
2024-07-10 17:21:32 <@siosm:matrix.org> should we vote on firewalld before?
2024-07-10 17:21:45 <@siosm:matrix.org> =1
2024-07-10 17:21:46 <@siosm:matrix.org> +1
2024-07-10 17:21:49 <@apiaseck:matrix.org> +1
2024-07-10 17:22:07 <@jbtrystram:matrix.org> +1
2024-07-10 17:22:07 <@marmijo:fedora.im> +1
2024-07-10 17:22:07 <@hricky:fedora.im> I think you already said what is important.
2024-07-10 17:22:10 <@dustymabe:matrix.org> Jonathan Lebon: along with rationale on why we think running containers reduces the need for an active firewall 
2024-07-10 17:22:25 <@jlebon:fedora.im> dustymabe: will amend in the agreed
2024-07-10 17:23:11 <@dustymabe:matrix.org> we should probably also include examples of basic iptables/nftables usage (i.e. butane configs that allow access to a specific port or something)
2024-07-10 17:23:50 <@apiaseck:matrix.org> Any other votes for proposed?
2024-07-10 17:24:00 <@hricky:fedora.im> +1
2024-07-10 17:24:10 <@jlebon:fedora.im> dustymabe: will amend the agreed :)
2024-07-10 17:24:14 <@dustymabe:matrix.org> +1
2024-07-10 17:24:22 <@jlebon:fedora.im> !agreed: currently, we are not considering adding firewalld by default. we will however add documention detailing the rationale for this, as well as every port open by default, example nftables configs, and instructions on how to add firewalld to the host.
2024-07-10 17:25:20 <@jlebon:fedora.im> with the bit of time left, can we discuss https://github.com/coreos/fedora-coreos-docs/issues/650 ?
2024-07-10 17:25:26 <@siosm:matrix.org> we have https://github.com/coreos/fedora-coreos-docs/issues/247 that we can re-purpose
2024-07-10 17:25:55 <@apiaseck:matrix.org> !topic  Document ways to contribute to FCOS
2024-07-10 17:26:11 <@apiaseck:matrix.org> !link https://github.com/coreos/fedora-coreos-docs/issues/650
2024-07-10 17:26:50 <@jlebon:fedora.im> we've identified a need to better document how to contribute to FCOS
2024-07-10 17:27:14 <@jlebon:fedora.im> the current proposal is to add a new top-level "Contributing" page to the docs
2024-07-10 17:28:19 <@jlebon:fedora.im> though we should also start to think about developing a process for community members to contribute to the more privileged parts of maintenance, such as FCOS release rotation and general infra maintenance
2024-07-10 17:28:38 <@jlebon:fedora.im> see https://github.com/coreos/fedora-coreos-docs/issues/650#issuecomment-2220354989 and following
2024-07-10 17:28:38 <@jlebon:fedora.im> Hristo Marinov indicated some interest there
2024-07-10 17:29:52 <@jlebon:fedora.im> this is a large topic on its own, but wanted to see if there's agreement on the overall direction
2024-07-10 17:30:17 <@dustymabe:matrix.org> +1 to adding a new top level contributing page 
2024-07-10 17:30:42 <@siosm:matrix.org> I think that apart from the release side of things, everything should be open to anyone for contributions. +1 for a dedicated page
2024-07-10 17:31:05 <@siosm:matrix.org> should "already" be opne
2024-07-10 17:31:10 <@siosm:matrix.org> should "already" be open
2024-07-10 17:31:20 <@marmijo:fedora.im> +1 from me as well
2024-07-10 17:31:47 <@jlebon:fedora.im> i found https://fedoraproject.org/wiki/Infrastructure_Apprentice interesting; the "read-only access" phase of the process
2024-07-10 17:32:27 <@jlebon:fedora.im> i think that'd require some rejigging in the ansible bits for our openshift projects if we wanted to do something analogous
2024-07-10 17:33:08 <@siosm:matrix.org> I'm warry of the amount of work needed to make our release pipeline safe or read only
2024-07-10 17:33:33 <@siosm:matrix.org> i.e. Jenkins has an awefull track record in terms of security
2024-07-10 17:33:49 <@siosm:matrix.org> i.e. Jenkins has an awful track record in terms of security
2024-07-10 17:34:10 <@jlebon:fedora.im> travier: i don't mean read-only by default. but allow some contributors to have read-only access to start
2024-07-10 17:34:26 <@jlebon:fedora.im> but anyway, maybe the simplest/most appropriate is to piggyback on the existing infrastructure processes
2024-07-10 17:34:41 <@apiaseck:matrix.org> side note: we are stretching allocated time. 
2024-07-10 17:35:22 <@jlebon:fedora.im> yes, we can close this. sounds like there's overall agreement there to discuss further
2024-07-10 17:35:27 <@siosm:matrix.org> overall, I feel that there are bigger wins outside of the release part of things
2024-07-10 17:36:40 <@siosm:matrix.org> Cloud platform support is top one from my perspective
2024-07-10 17:36:44 <@jlebon:fedora.im> travier: i think it's more philosophically, this should be possible
2024-07-10 17:36:49 <@siosm:matrix.org> Cloud platform support is a top one from my perspective
2024-07-10 17:37:06 <@apiaseck:matrix.org> Should we write up the `agreed` here, or move this topic another meeting? 
2024-07-10 17:37:13 <@jlebon:fedora.im> in my opinion, part of the "trust building" process would be to work on those issues
2024-07-10 17:37:21 <@apiaseck:matrix.org> I feel like there is so much more to discuss here...
2024-07-10 17:37:28 <@siosm:matrix.org> hopefully with Konflux, this becomes a non issue and anyone can setup their own pipeline
2024-07-10 17:37:38 <@siosm:matrix.org> but we're clearly not there yet
2024-07-10 17:38:39 <@siosm:matrix.org> I'll stop here so that we can close. I don't think we specifically need an agreed to add a page to the docs?
2024-07-10 17:38:44 <@jlebon:fedora.im> apiaseck: i think we can close :)
2024-07-10 17:39:10 <@apiaseck:matrix.org> Perfect, thank you all.
2024-07-10 17:39:11 <@apiaseck:matrix.org> !topic Open Floor
2024-07-10 17:39:44 <@apiaseck:matrix.org> Is there anything else pressing folks?
2024-07-10 17:40:42 <@apiaseck:matrix.org> If not, it's been a pleasure! Thank you for the discussion and see you on the next one!
2024-07-10 17:41:08 <@apiaseck:matrix.org> !endmeeting