<@jbtrystram:matrix.org>
16:31:17
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:31:19
Meeting started at 2025-02-05 16:31:17 UTC
<@meetbot:fedora.im>
16:31:19
The Meeting name is 'fedora_coreos_meeting'
<@jbtrystram:matrix.org>
16:31:26
!topic roll call
<@dustymabe:matrix.org>
16:31:29
!hi
<@jbtrystram:matrix.org>
16:31:30
!hi
<@zodbot:fedora.im>
16:31:31
Dusty Mabe (dustymabe) - he / him / his
<@zodbot:fedora.im>
16:31:33
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@ravanelli:matrix.org>
16:31:50
!hi ravanelli
<@zodbot:fedora.im>
16:31:52
Renata Ravanelli (ravanelli)
<@hricky:fedora.im>
16:32:10
!hi
<@zodbot:fedora.im>
16:32:11
Hristo Marinov (hricky) - he / him / his
<@siosm:matrix.org>
16:32:12
!hi
<@zodbot:fedora.im>
16:32:13
Timothée Ravier (siosm) - he / him / his
<@marmijo:fedora.im>
16:32:14
!hi
<@zodbot:fedora.im>
16:32:16
Michael Armijo (marmijo)
<@aaradhak:matrix.org>
16:33:24
!hi aaradhak
<@jbtrystram:matrix.org>
16:33:25
Hi everyone :)
<@zodbot:fedora.im>
16:33:26
Aashish Radhakrishnan (aaradhak)
<@jbtrystram:matrix.org>
16:33:31
!topic Action items from last meeting
<@jbtrystram:matrix.org>
16:33:52
I see no actions items in last week meeting notes
<@siosm:matrix.org>
16:34:03
(Note: I have a side item for discussion that is not in a tracker ticket: https://github.com/coreos/ignition/pull/1923#issuecomment-2631451532)
<@jbtrystram:matrix.org>
16:34:21
travier: let's start with that
<@jbtrystram:matrix.org>
16:34:34
!topic Add azure blob support
<@jbtrystram:matrix.org>
16:34:40
<@siosm:matrix.org>
16:36:02
The idea is that Steven added support for access protected Azure blob storage as an option to store the Ignition config in Azure
<@jlebon:fedora.im>
16:36:09
!hi
<@zodbot:fedora.im>
16:36:10
None (jlebon)
<@jbtrystram:matrix.org>
16:36:38
sounds cool . Thanks spresti !
<@siosm:matrix.org>
16:37:27
In itself, this is all fine. The trick is that it's a feature that is not tied to a spec version right now: https://github.com/coreos/fedora-coreos-docs/pull/702
<@siosm:matrix.org>
16:38:15
as the "only" difference is the URL to access the ressource
<@siosm:matrix.org>
16:38:55
this is similar in idea to https://coreos.github.io/ignition/operator-notes/#aws-s3-access
<@siosm:matrix.org>
16:39:31
normally we would have added that support to a spec version, updated the docs, stabilized the spec, etc.
<@siosm:matrix.org>
16:39:45
we "could"
<@siosm:matrix.org>
16:40:10
here it's only to work not depending on a spec release but depending on the version of ignition used in the system
<@siosm:matrix.org>
16:40:28
so I'm wondering if we should keep it as is or do something else / a spec version change instead
<@dustymabe:matrix.org>
16:40:42
ideally we'd do what we did in the past
<@dustymabe:matrix.org>
16:41:11
but practically maybe we choose to do something different
<@dustymabe:matrix.org>
16:41:25
what's the failure scenario here ?
<@siosm:matrix.org>
16:41:41
ignition does not get the config AFAIK
<@siosm:matrix.org>
16:41:56
it's something that does not work right now so I don't expect people to be using it
<@siosm:matrix.org>
16:42:15
i.e. it should be an HTTP error AFAIK
<@siosm:matrix.org>
16:42:43
So we could document that it's supported "starting with FCOS version X.Y.Z"
<@dustymabe:matrix.org>
16:43:20
ok so the URL is basically just a URL still, but Ignition will do some magic if on azure and URL matches some pattern ?
<@mnguyen:fedora.im>
16:43:28
!hi mnguyen
<@zodbot:fedora.im>
16:43:29
Michael Nguyen (mnguyen)
<@siosm:matrix.org>
16:43:30
yes
<@dustymabe:matrix.org>
16:43:35
ok so the URL is basically just a URL still (https), but Ignition will do some magic if on azure and URL matches some pattern ?
<@jlebon:fedora.im>
16:43:36
is there a legitimate use of that URL _prior_ to this work? i.e. could a blob be posted there that is public and could be in use?
<@siosm:matrix.org>
16:43:51
https://github.com/coreos/ignition/pull/1923/commits/5f5d863c01c4fb1bae7acf496391cbcd01c365d6#diff-7c9c2af4308276751a9147e0599d55f3982255dedcf415c0ee350febd6629fd7R219
<@siosm:matrix.org>
16:44:36
it's possible that it could be used today but it would be without any authentication
<@jlebon:fedora.im>
16:44:38
yeah, unlike some of the other supported cloud storage schemes, there isn't one for Azure that would've made this a very clear feature add
<@jlebon:fedora.im>
16:45:02
my concern i think is that this is changing the semantics of potential URLs currently in use
<@dustymabe:matrix.org>
16:45:08
> it's possible that it could be used today but it would be without any authentication
<@dustymabe:matrix.org>
16:45:08
<@dustymabe:matrix.org>
16:45:08
to be clear here.. we didn't regress this use case ^^ correct ?
<@jlebon:fedora.im>
16:45:11
so in that respect, maybe we _should_ gate it on a spec version
<@siosm:matrix.org>
16:45:41
well, I don't know, I hope not but I don't really know
<@siosm:matrix.org>
16:45:59
maybe spresti knows more
<@dustymabe:matrix.org>
16:46:02
did we (or will we) add an automated test for the feature?
<@dustymabe:matrix.org>
16:46:15
did we (or will we) add an automated test for the feature? if so we could test private and public access
<@dustymabe:matrix.org>
16:46:22
for public access we could just test on a non-azure VM
<@jlebon:fedora.im>
16:46:46
the new code right now hard fails in a bunch of places, e.g. it fails to fetch credentials. so those would be new error paths old configs could fall into
<@siosm:matrix.org>
16:46:48
I've added automated tests to the planning
<@jlebon:fedora.im>
16:47:30
are those URLs only usable within Azure?
<@jlebon:fedora.im>
16:47:47
(in the public anonymous case)
<@siosm:matrix.org>
16:48:51
I don't know :/
<@dustymabe:matrix.org>
16:49:52
I'm thinking if this only enables a feature to work that never worked before and doesn't regress any previous use cases; then I'm OK with no spec bump.
<@dustymabe:matrix.org>
16:49:52
The downside of the spec bump is it's basically a bunch more work to get to the end goal, correct? and obviously the indeterminism of "must use newer Ignition for this feature", but I think I'm OK with that.
<@dustymabe:matrix.org>
16:49:52
<@siosm:matrix.org>
16:50:31
works for me, so we have to make sure not to regress
<@dustymabe:matrix.org>
16:50:54
yeah, basically what I would do is just make sure we have tests for all the cases we care about
<@dustymabe:matrix.org>
16:51:19
which shouldn't be too hard I don't think with some test fixtures like we have for aws s3
<@dustymabe:matrix.org>
16:51:43
one thing to think about also, is the flatcar team might have thoughts/opinions here too
<@jlebon:fedora.im>
16:51:45
right, we need some investigation there.
<@jlebon:fedora.im>
16:51:45
hmm, maybe we should've gone with a made up scheme e.g. az://
<@jlebon:fedora.im>
16:52:15
but that doesn't feel great either. i would prefer a spec bump if it comes to it
<@dustymabe:matrix.org>
16:52:18
are any of our other schemes made up? I feel like that would be a bit awkward
<@jlebon:fedora.im>
16:52:25
no
<@dustymabe:matrix.org>
16:53:17
there are two ways to look at this work:
<@dustymabe:matrix.org>
16:53:17
<@dustymabe:matrix.org>
16:53:17
1. a feature
<@dustymabe:matrix.org>
16:53:17
2. a bug that is now getting fixed (i.e. it should have worked in the past)
<@dustymabe:matrix.org>
16:53:17
<@dustymabe:matrix.org>
16:53:17
in the case of 2. no spec bump is appreciated :)
<@jlebon:fedora.im>
16:56:19
hmm, seems a bit of a stretch to see it as a bugfix :)
<@siosm:matrix.org>
16:56:39
:)
<@jlebon:fedora.im>
16:56:47
but yeah, if it doesn't cause any regressions, WFM!
<@jlebon:fedora.im>
16:56:54
i think we need an Azure SME
<@dustymabe:matrix.org>
16:57:08
well, flatcar folks do work for MSFT
<@siosm:matrix.org>
16:57:21
OK, I'll make an issue in the ignition repo to track that discussion and we'll focus on testing this before we move forward
<@siosm:matrix.org>
16:57:49
well, this is similar to saying that we are Satellite experts :)
<@jlebon:fedora.im>
16:58:00
dustymabe: good call. either they'd know or could help us find someone who would
<@siosm:matrix.org>
16:58:07
but agree that we can ask!
<@jbtrystram:matrix.org>
16:59:44
So, action: travier to file an issue to gate the release of the azure blob support to more testing ?
<@siosm:matrix.org>
16:59:55
I'm filling it now :)
<@siosm:matrix.org>
17:00:09
I think we can move to the next topic
<@jbtrystram:matrix.org>
17:00:17
Okay !
<@jbtrystram:matrix.org>
17:00:29
!topic Implement Proxmox VE
<@jbtrystram:matrix.org>
17:00:34
<@jbtrystram:matrix.org>
17:01:28
Jonathan Lebon: you added the meeting label on that, it's been open for a while, do you want to give an update?
<@jlebon:fedora.im>
17:02:47
sure
<@jlebon:fedora.im>
17:03:34
bri wrote some code for restamping the QEMU image for proxmox
<@jlebon:fedora.im>
17:04:29
we'll need similar code for e.g. oracle
<@siosm:matrix.org>
17:04:35
bri?
<@jlebon:fedora.im>
17:04:51
we discussed this in e.g. https://github.com/coreos/fedora-coreos-docs/pull/652 in the past
<@jlebon:fedora.im>
17:05:25
travier: that's what i see as their name on their profile :) https://github.com/b-
<@jlebon:fedora.im>
17:05:46
so there's opportunity there to generalize it, containerize it, and use that in the docs
<@jlebon:fedora.im>
17:05:52
for proxmox and OCI
<@jlebon:fedora.im>
17:06:17
dustymabe: i think part of it is just people showing up to do the work
<@marmijo:fedora.im>
17:06:36
I'm running FCOS in proxmox currently, so I can help with any of this work!
<@jbtrystram:matrix.org>
17:07:00
I think Adam also showed interrest in having proxmox support for his homelab setup as well
<@jlebon:fedora.im>
17:07:13
personally, if someone shows up and wants to build disk images for proxmox, that WFM
<@dustymabe:matrix.org>
17:07:30
I think maybe we should let them know that
<@dustymabe:matrix.org>
17:08:05
I could see us actually demoting some of our images we produce for others that are more popular
<@dustymabe:matrix.org>
17:08:29
i.e. exoscale (maybe not very popular) with proxmox as an example?
<@dustymabe:matrix.org>
17:09:15
but that is a different conversation to have probably
<@jlebon:fedora.im>
17:09:56
yeah, mostly i wanted to bring up the idea of taking that repo and building on top of it for emerging platforms
<@jlebon:fedora.im>
17:10:22
because i think that's the biggest gap in that story, and having long scripts in the docs is not great
<@marmijo:fedora.im>
17:10:48
you're talking about bri's restamper repo?
<@siosm:matrix.org>
17:11:19
the content of the repo is mostly a copy/paste of the script as far as I can see so we could definitely put all of that into a container directly to be used in GitHub Actions
<@dustymabe:matrix.org>
17:12:43
how much is it worth managing a separate tool versus just baking it into COSA
<@dustymabe:matrix.org>
17:12:52
(that already has all the deps one would need)
<@jlebon:fedora.im>
17:14:14
dustymabe: not strongly against. we just don't really think of cosa as user-facing. and the UX of pulling down multiple gigs is not great.
<@siosm:matrix.org>
17:14:53
well, isn't most of it libvirt & co and that would be part of the new container as well?
<@jlebon:fedora.im>
17:16:44
hmm... i doubt it's "most of it" but we should see, yeah
<@siosm:matrix.org>
17:18:10
sure worth giving it a try
<@jlebon:fedora.im>
17:19:16
```
<@jlebon:fedora.im>
17:19:16
$ rpm -qa | grep -e libguestfs -e qemu -e libvirt | xargs -n 1 rpm -q --qf '%{size}\n' | awk '{ sum += $1 } END { print sum }'
<@jlebon:fedora.im>
17:19:16
381766149
<@jlebon:fedora.im>
17:19:16
```
<@jlebon:fedora.im>
17:19:25
380M
<@dustymabe:matrix.org>
17:19:30
<@dustymabe:matrix.org>
17:19:30
summary:
<@dustymabe:matrix.org>
17:19:30
- I don't hear anyone opposed to a restamper tool existing and maybe even having a stamp of approval
<@dustymabe:matrix.org>
17:19:30
- some questions on the best way to manage it (i.e. just making it a subcommand in COSA could be an option)
<@dustymabe:matrix.org>
17:19:30
- also no one is opposed to having proxmox be a toplevel platform if somebody would like to put in the work to make that happen
<@jlebon:fedora.im>
17:19:59
364M
<@marmijo:fedora.im>
17:20:49
I'm fully on board with having proxmox be a top level platform. I think FCOS would be useful in the homelab space (where a lot of people use proxmox)
<@siosm:matrix.org>
17:21:02
+1
<@marmijo:fedora.im>
17:21:43
I'm fully on board with having proxmox be a top level platform. I think FCOS <del>would be</del> IS useful in the homelab space (where a lot of people use proxmox)
<@siosm:matrix.org>
17:22:59
Let's do a proposed for adding proxmox?
<@siosm:matrix.org>
17:23:03
adding images*
<@jbtrystram:matrix.org>
17:23:20
I don't think this bot works with proposed
<@siosm:matrix.org>
17:23:40
the bot won't note it but we can still do it :)
<@jbtrystram:matrix.org>
17:23:46
yeah
<@jbtrystram:matrix.org>
17:24:17
proposed: Make proxmox a toplevel platform for Fedora CoreOS
<@dustymabe:matrix.org>
17:25:19
WFM - especially considering we have a community member willing to create docs and seemingly put in the work
<@siosm:matrix.org>
17:25:32
+1 to proposed
<@dustymabe:matrix.org>
17:25:33
👍
<@jbtrystram:matrix.org>
17:25:34
and 2nd proposed: reach to bri to move the restamper tool to a container in the CoreOS org and write up the documentation for it
<@marmijo:fedora.im>
17:25:52
+1 to first, +1 to second
<@jlebon:fedora.im>
17:27:16
hmm, didn't explicitly ask bri about doing the work, just whether they'd like to transfer the repo over
<@dustymabe:matrix.org>
17:27:49
ehh - I feel like if we move the restamper tool to our org we should be willing to "own" it more
<@jlebon:fedora.im>
17:28:02
i don't think they would be if proxmox is being promoted
<@jlebon:fedora.im>
17:28:09
i don't think they would be interested if proxmox is being promoted
<@dustymabe:matrix.org>
17:28:45
i.e. the GHA in the repo.. is that something we're going to run for emerging platforms? or is this just an example that people can form for themselves?
<@jlebon:fedora.im>
17:28:52
yeah, i didn't expect more work from them. just a seed repo and then we can build on top
<@siosm:matrix.org>
17:28:53
let's keep the restamp part distinct from the proxmox platform
<@dustymabe:matrix.org>
17:29:03
i.e. the GHA in the repo.. is that something we're going to run for emerging platforms? or is this just an example that people can use for themselves?
<@dustymabe:matrix.org>
17:29:37
maybe let's open a separate ticket for the restamper discussion
<@jbtrystram:matrix.org>
17:29:44
that's why i did 2 proposed :)
<@jbtrystram:matrix.org>
17:30:05
agreed! Make proxmox a toplevel platform for Fedora CoreOS
<@jbtrystram:matrix.org>
17:30:17
!agreed Make proxmox a toplevel platform for Fedora CoreOS
<@siosm:matrix.org>
17:31:11
It's a GitHub Action to do the restamp. It could be "simpler" if we had a container with all the tools and script but not by much
<@siosm:matrix.org>
17:31:28
we are at time
<@siosm:matrix.org>
17:31:50
let's discuss that again next time?
<@jbtrystram:matrix.org>
17:31:59
yeah
<@jbtrystram:matrix.org>
17:32:09
i'll let the meeting label there
<@marmijo:fedora.im>
17:32:53
We could do as dustymabe suggested and open a separate ticket for the restamper discussion
<@jlebon:fedora.im>
17:32:59
hmm, i misunderstood you then. i thought you meant a GHA to publish the tool as a container. i'm picturing the docs saying "run `podman run ...` to get an Oracle image", and not "set up GHA..."
<@jlebon:fedora.im>
17:32:59
> It's a GitHub Action to do the restamp.
<@jlebon:fedora.im>
17:33:03
hmm, i misunderstood you then. i thought you meant a GHA to publish the tool as a container. i'm picturing the docs saying "run `podman run ...` to get an Oracle image", and not "set up GHA..."
<@jlebon:fedora.im>
17:33:03
<@jlebon:fedora.im>
17:33:03
> It's a GitHub Action to do the restamp.
<@jlebon:fedora.im>
17:33:28
ack, let's continue next week
<@dustymabe:matrix.org>
17:33:29
This is what I would prefer ^^
<@siosm:matrix.org>
17:33:38
jbtrystram: Can you link to the meeting notes in https://github.com/coreos/ignition/issues/2011 for the Ignition discussion? Thanks
<@jbtrystram:matrix.org>
17:33:53
Sure
<@jbtrystram:matrix.org>
17:34:32
allright, thanks all for joining !
<@jlebon:fedora.im>
17:34:44
thanks all, thanks jbtrystram for running!
<@jbtrystram:matrix.org>
17:34:44
!endmeeting