<@siosm:matrix.org>
16:35:32
!startmeeting fedora_coreos_meeting
<@meetbot:fedora.im>
16:35:34
Meeting started at 2024-02-14 16:35:32 UTC
<@meetbot:fedora.im>
16:35:34
The Meeting name is 'fedora_coreos_meeting'
<@siosm:matrix.org>
16:35:52
Starting the meeting (JB can take over once he gets here)
<@siosm:matrix.org>
16:35:59
!topic roll call
<@jbtrystram:matrix.org>
16:36:11
!hi jbtrystram
<@zodbot:fedora.im>
16:36:14
Jean-Baptiste Trystram (jbtrystram) - he / him / his
<@aaradhak:matrix.org>
16:36:21
!hi aaradhak
<@zodbot:fedora.im>
16:36:23
Aashish Radhakrishnan (aaradhak)
<@apiaseck:matrix.org>
16:36:33
!hi c4rt0
<@zodbot:fedora.im>
16:36:35
Adam Piasecki (c4rt0) - he / him / his
<@siosm:matrix.org>
16:36:38
I'll let you handle the meeting then jbtrystram https://github.com/coreos/fcos-meeting-action/issues/71
<@siosm:matrix.org>
16:36:49
!hi
<@zodbot:fedora.im>
16:36:51
Timothée Ravier (siosm) - he / him / his
<@marmijo:fedora.im>
16:36:52
!hi marmijo
<@zodbot:fedora.im>
16:36:53
Michael Armijo (marmijo)
<@dustymabe:matrix.org>
16:36:58
!hi
<@jmarrero:matrix.org>
16:36:59
!hi jmarrero
<@zodbot:fedora.im>
16:37:00
Dusty Mabe (dustymabe) - he / him / his
<@zodbot:fedora.im>
16:37:01
Joseph Marrero (jmarrero)
<@jbtrystram:matrix.org>
16:37:05
@travier sorry ! Thanks
<@spresti:fedora.im>
16:37:23
!hi
<@zodbot:fedora.im>
16:37:24
Steven Presti (spresti)
<@jbtrystram:matrix.org>
16:39:01
I'll wait another minute for everyone to join and start
<@gurssing:matrix.org>
16:39:41
!hi gursewak
<@zodbot:fedora.im>
16:39:43
Gursewak Singh (gursewak)
<@jbtrystram:matrix.org>
16:39:51
!topic Action items from last meeting
<@siosm:matrix.org>
16:40:49
Minutes from last week: https://discussion.fedoraproject.org/t/fedora-coreos-community-meeting-minutes-2024-02-07/104665
<@jlebon:fedora.im>
16:40:56
!hi
<@zodbot:fedora.im>
16:40:57
None (jlebon)
<@spresti:fedora.im>
16:40:59
Ah i was about to do that
<@spresti:fedora.im>
16:41:15
There were no action items
<@siosm:matrix.org>
16:41:23
There is not action label in the tracker, it's only listed in the meeting minutes :)
<@siosm:matrix.org>
16:41:31
There is no action label in the tracker, it's only listed in the meeting minutes :)
<@jbtrystram:matrix.org>
16:41:51
Ah okay, then there is none :)
<@spresti:fedora.im>
16:42:16
Sorry guys https://github.com/coreos/fcos-meeting-action/pull/69 is almost there.
<@jbtrystram:matrix.org>
16:42:35
!info no actions to do since last meeting
<@ravanelli:matrix.org>
16:43:58
.hi
<@jbtrystram:matrix.org>
16:44:02
!topic tracker: Fedora 40 changes considerations
<@jbtrystram:matrix.org>
16:44:09
!link https://github.com/coreos/fedora-coreos-tracker/issues/1626
<@dustymabe:matrix.org>
16:44:37
there are some new self contained changes for us to run through. shouldn't take long
<@jbtrystram:matrix.org>
16:45:10
I do one action for each new entry in the tracker bug ?
<@jbtrystram:matrix.org>
16:45:14
one topic sorry
<@spresti:fedora.im>
16:45:29
Do an info
<@siosm:matrix.org>
16:45:37
You can do !info ... & !link to the change URL
<@spresti:fedora.im>
16:45:37
or topic rather
<@siosm:matrix.org>
16:45:45
or topic
<@jbtrystram:matrix.org>
16:46:04
!topic ibus-anthy 1.5.16 will update the Japanese era for 2024.
<@jbtrystram:matrix.org>
16:46:12
!link https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.16
<@siosm:matrix.org>
16:46:27
We don't ship ibus so that should not impact us
<@spresti:fedora.im>
16:46:58
!info we dont ship ibus, so not impacted
<@jbtrystram:matrix.org>
16:47:37
!topic IBus 1.5.30
<@jbtrystram:matrix.org>
16:47:49
!link https://fedoraproject.org/wiki/Changes/IBus_1.5.30
<@spresti:fedora.im>
16:47:56
Same thing ?
<@jbtrystram:matrix.org>
16:47:57
!info we dont ship ibus, so not impacted
<@jlebon:fedora.im>
16:47:59
yup
<@jbtrystram:matrix.org>
16:48:26
!topic IoT Simplified Provisioning : Offer Fedora IoT users a new, non-release blocking deliverable to deploy and configure Fedora IoT systems using a new tool called Simplified Provisioning.
<@jbtrystram:matrix.org>
16:48:31
!link https://fedoraproject.org/wiki/Changes/IoTSimplifiedProvisioning
<@jlebon:fedora.im>
16:49:07
this one is good to be aware of, but doesn't directly impact us either. IoT is a known user/contributor of coreos-installer
<@spresti:fedora.im>
16:49:30
thats awesome :)
<@jbtrystram:matrix.org>
16:50:53
proposed info: We won't ship Simplified Provisioning, but it's good to be aware as IoT is a known user/contributor of coreos-installer
<@jbtrystram:matrix.org>
16:51:55
!info: We won't ship Simplified Provisioning, but it's good to be aware as IoT is a known user/contributor of coreos-installer
<@jbtrystram:matrix.org>
16:52:37
I'll let steven finish his message before moving on :)
<@spresti:fedora.im>
16:52:46
nooo lol im good
<@spresti:fedora.im>
16:52:50
sorry
<@jbtrystram:matrix.org>
16:53:03
:)
<@jbtrystram:matrix.org>
16:53:05
!topic Deprecate_ntlm_in_cyrus_sasl
<@jbtrystram:matrix.org>
16:53:11
!link https://fedoraproject.org/wiki/Changes/Deprecate_ntlm_in_cyrus_sasl
<@jlebon:fedora.im>
16:53:14
we do ship cyrus-sasl but IMO this is not even worth signaling in our communications
<@spresti:fedora.im>
16:53:14
Looking at our manifest files do we even ship ntlm_in_cyrus_sasl?
<@spresti:fedora.im>
16:53:43
(lol caught prepping for next question)
<@spresti:fedora.im>
16:53:53
Ah ok
<@spresti:fedora.im>
16:54:43
For future ref Jonathan Lebon where do I look to see if we infact do ship somthing?
<@siosm:matrix.org>
16:54:53
we don't ship the cyrus-sasl-ntlm subpackage however
<@jlebon:fedora.im>
16:55:01
you can git grep the f-c-c repo
<@siosm:matrix.org>
16:55:12
I'm running `rpm -qa` on my FCOS nodes
<@spresti:fedora.im>
16:55:24
ah ok, i was only looking at the lockfile
<@jlebon:fedora.im>
16:55:56
travier: good catch. so this shouldn't affect us at all
<@jbtrystram:matrix.org>
16:57:33
so proposed : we don't ship the cyrus-sasl-ntlm subpackage
<@jbtrystram:matrix.org>
16:57:43
so proposed : we don't ship the cyrus-sasl-ntlm subpackage, so not impacted
<@jbtrystram:matrix.org>
16:58:59
!info we don't ship the cyrus-sasl-ntlm subpackage, so not impacted
<@siosm:matrix.org>
16:59:10
(you can skip proposed when we don't even include the package)
<@jbtrystram:matrix.org>
16:59:28
!topic Please provide FCOS OVA image for VMware on aarch64/MacOS
<@jbtrystram:matrix.org>
16:59:34
!link https://github.com/coreos/fedora-coreos-tracker/issues/1594
<@siosm:matrix.org>
16:59:49
you missed a change?
<@siosm:matrix.org>
17:00:00
227?
<@siosm:matrix.org>
17:00:09
Didn't you miss a change?
<@siosm:matrix.org>
17:00:29
It's a quick one as it does not impact us
<@jbtrystram:matrix.org>
17:00:29
ah yes ! Sorry
<@jbtrystram:matrix.org>
17:00:43
I even had prepped it
<@jbtrystram:matrix.org>
17:00:57
let's discuss this one then circle back ?
<@spresti:fedora.im>
17:01:10
sgtm
<@apiaseck:matrix.org>
17:01:17
+1
<@dustymabe:matrix.org>
17:01:25
I tagged this with one with meeting label
<@dustymabe:matrix.org>
17:02:02
looks like we have more and more people with M* mac hardware out there (aarch64)
<@jlebon:fedora.im>
17:02:04
(basically 227 is "this doesn't directly impact us but is good news")
<@ravanelli:matrix.org>
17:02:48
the new Mac hardware is only aarch64
<@ravanelli:matrix.org>
17:03:01
I think make sense to have it
<@dustymabe:matrix.org>
17:03:02
Renata Ravanelli: yes
<@jbtrystram:matrix.org>
17:03:03
@jlebon @travier i updated the tracking issue with the info, is it worth adding a topic in the meeting note?
<@jlebon:fedora.im>
17:04:02
jbtrystram: it'd be out of order now. i'd just omit it
<@dustymabe:matrix.org>
17:04:29
this one should be simple. I think all we have to do is just add the artifact to the aarch64 list in our pipeline: https://github.com/coreos/fedora-coreos-pipeline/blob/fb1c673c4f391b973c84726fc9c99366330899ad/config.yaml#L56
<@jlebon:fedora.im>
17:04:52
dustymabe: i don't quite follow
<@jlebon:fedora.im>
17:05:03
the ticket is talking about VMware
<@jlebon:fedora.im>
17:05:37
are there people wanting to run VMware on their Mac?
<@spresti:fedora.im>
17:06:01
It seems like it, for testing purposes.
<@jlebon:fedora.im>
17:06:40
ok weird
<@dustymabe:matrix.org>
17:06:57
Jonathan Lebon: yeah. same as they were running VMWare Fusion on their Mac prior to Apple transitioning to aarch64
<@dustymabe:matrix.org>
17:07:10
they want to run it now too, just with aarch64 as the arch
<@ravanelli:matrix.org>
17:07:29
I do run fcos via virtual box for example in my Mac to test things.
<@jlebon:fedora.im>
17:07:40
i mean, i would position it as building it for VMware's sake. Mac users getting to test it locally is sort of an implied thing
<@spresti:fedora.im>
17:07:42
yeah mac's with the new apple chips are quite limited with virt options
<@jlebon:fedora.im>
17:08:21
ahh OK. they're not testing locally to push to some other cluster, but using VMware as *the* virtualization stack they want to use on their Mac
<@ravanelli:matrix.org>
17:08:35
spresti: indeed, seems it also dropped kvm
<@jlebon:fedora.im>
17:08:43
ahh OK. they're not testing locally to push to some other VMware cluster, but using VMware as _the_ virtualization stack they want to use on their Mac
<@spresti:fedora.im>
17:08:47
yeah
<@jlebon:fedora.im>
17:08:57
that makes more sense now :)
<@spresti:fedora.im>
17:09:46
So are there any storage concerns for adding another variant ?
<@jbtrystram:matrix.org>
17:10:01
i would expect vmware to handle a regular qcow2 file ?
<@spresti:fedora.im>
17:10:36
yeah but virting x86 to aarch is rough.
<@spresti:fedora.im>
17:10:49
or rather other way around
<@jlebon:fedora.im>
17:10:50
jbtrystram: it's a different platform ID, e.g. Ignition provisioning works differently
<@jlebon:fedora.im>
17:12:07
i don't mind the storage part of it. the bigger issue in that area is honestly our lack of GC
<@dustymabe:matrix.org>
17:12:38
Yes IIUC gursewak was working on garbage collection
<@dustymabe:matrix.org>
17:12:56
but it's a huge problem of ours
<@jlebon:fedora.im>
17:13:20
honestly, we should probably stop building any image we don't actually test on mechanical streams. at least until we get GC
<@jbtrystram:matrix.org>
17:14:03
it sounds crazy that we would need to have a different image that is probably 99% the same, except for some metadata pointing to the ignition file :) but i don't know much about virtualisation to have strong opinions
<@jbtrystram:matrix.org>
17:14:18
it sounds crazy that we would need to have a different image that is probably 99% the same, except for some metadata pointing to the ignition file :) but i don't know enough about virtualisation to have strong opinions
<@jlebon:fedora.im>
17:14:32
jbtrystram: that is the bed we've made ourselves :). it has positives and negatives for sure
<@siosm:matrix.org>
17:14:55
jbtrystram: It's the idea behind the https://github.com/coreos/fedora-coreos-tracker/blob/main/.github/ISSUE_TEMPLATE/implementing-new-emerging-platform.md template
<@spresti:fedora.im>
17:14:59
I think the platform ID was the anchor we needed for a chicken and egg issue
<@siosm:matrix.org>
17:15:55
If we can make a set commands that coverts an existing image to a VMware OVA that could also be an option
<@siosm:matrix.org>
17:16:37
But it's always going to be nicer for users if we provide the image exactly as is
<@dustymabe:matrix.org>
17:17:41
I think what @jlebon said is more relevant here on the storage issue.
<@siosm:matrix.org>
17:17:48
See also a previous idea from Colin: https://github.com/cgwalters/coreos-diskimage-rehydrator
<@dustymabe:matrix.org>
17:17:55
if we're worried about storage, we should really finally implement GC
<@dustymabe:matrix.org>
17:18:12
and then focus on other efforts after that
<@dustymabe:matrix.org>
17:18:19
GC would give the much bigger win
<@jbtrystram:matrix.org>
17:18:43
Jonathan Lebon: what does "mechanical stream" means in this context ?
<@siosm:matrix.org>
17:19:08
It's a stream that is released automatically
<@siosm:matrix.org>
17:19:25
i.e. we don't manually release Rawhide
<@siosm:matrix.org>
17:20:06
I agree that it would be nice to focus on garbage collecting our unused images.
<@gurssing:matrix.org>
17:20:32
On a side note dustymabe For the GC issue itself, it was decided that it is a much broader issue than expected and will need breaking it down to tackle it accordingly. No ongoing work rn.
<@jlebon:fedora.im>
17:21:39
yeah, i think we'll be prioritizing that one soon. but we can discuss that outside this meeting ;)
<@ravanelli:matrix.org>
17:21:53
Is there an open with for the GC?
<@siosm:matrix.org>
17:22:46
https://github.com/coreos/fedora-coreos-tracker/issues/99
<@jlebon:fedora.im>
17:23:01
re. the emerging platform bit, i see it more as a way for contributors to not have to jump through all the PR hoops. storage itself isn't a significant factor IMO.
<@jlebon:fedora.im>
17:23:27
IMO, since we already did all the work for vmware on x86_64, there isn't really anything to enable here
<@jlebon:fedora.im>
17:23:31
IOW, since we already did all the work for vmware on x86\_64, there isn't really anything to enable here
<@dustymabe:matrix.org>
17:25:28
I see this particular topic as a few questions/work items
1. should we add it?
2. someone does a local build and test on mac/vmware fusion (@fifofonix may be willing to do the test if someone else does the build)
3. add the entry to the artifact list in the pipeline
4. make sure it shows up on the website and in the builds browser
<@dustymabe:matrix.org>
17:26:20
if somehow the artifact doesn't work and would require us to debug it and spend more time on it, then I might not be up for making it a priority
<@dustymabe:matrix.org>
17:26:38
but if it's an easy win, then I'd vote for it
<@jlebon:fedora.im>
17:26:57
i'm not sure 4 is required
<@dustymabe:matrix.org>
17:27:14
why not?
<@jlebon:fedora.im>
17:27:30
sorry, "make sure" sounds good. but yeah, no work should be needed
<@dustymabe:matrix.org>
17:28:32
TBH fifofonix might be willing to do all the work here (it's that simple)
<@jlebon:fedora.im>
17:29:01
for 2, we could just turn it on in e.g. rawhide and let e.g. fifofonix test that
<@jbtrystram:matrix.org>
17:30:26
so it looks like this : agreed : we will test out an aarch64 vmware build with the help of @fifonix and if it works we enable vmware aarch64 in the pipeline
And then some action items for the next meeting
<@jbtrystram:matrix.org>
17:31:11
and also add a meeting topic about organising and re-prioritize the work around GC for images
<@dustymabe:matrix.org>
17:32:06
would be nice if we had a volunteer for collaborating with fifofonix too
<@dustymabe:matrix.org>
17:33:08
👋 fifofonix - welcome to the community where you get volunteered for things
<@fifofonix:matrix.org>
17:33:12
!hi fifofonix
<@zodbot:fedora.im>
17:33:14
Fifo Phonics (fifofonix)
<@spresti:fedora.im>
17:33:34
I have a mac with a aarch chip, I can see if I can test it as well.
<@mnguyen:fedora.im>
17:34:16
Thanks spresti
<@fifofonix:matrix.org>
17:34:51
I'd be happy to test, and if someone can explain what you regard as simple dustymabe, then I'm up for a challenge!
<@jlebon:fedora.im>
17:36:57
jbtrystram: want to do an approved and then we do a quick open floor?
<@jbtrystram:matrix.org>
17:37:15
!proposed: we will test out an aarch64 vmware build with the help of @fifonix and if it works, enable vmware + aarch64 in the pipeline
<@spresti:fedora.im>
17:37:29
+1
<@jlebon:fedora.im>
17:37:34
+1
<@ravanelli:matrix.org>
17:37:47
+1
<@mnguyen:fedora.im>
17:37:52
+1
<@apiaseck:matrix.org>
17:38:04
+1
<@jbtrystram:matrix.org>
17:38:11
(not usre if !proposed is a thing)
<@dustymabe:matrix.org>
17:38:13
+1
<@spresti:fedora.im>
17:38:21
Nah it used to be.
<@jbtrystram:matrix.org>
17:38:30
!agreed: we will test out an aarch64 vmware build with the help of @fifonix and if it works, enable vmware + aarch64 in the pipeline
<@spresti:fedora.im>
17:38:32
so you can do an agree'd
<@spresti:fedora.im>
17:39:05
odd the bot did not pick up
<@jbtrystram:matrix.org>
17:39:16
spresti: can we add a `hagrid` alias ? :)
<@spresti:fedora.im>
17:40:09
I am going to copy and paste your command real quick
<@jbtrystram:matrix.org>
17:40:11
i'll try again for the bot
<@spresti:fedora.im>
17:40:18
ok you go for it
<@jbtrystram:matrix.org>
17:40:18
!agreed: we will test out an aarch64 vmware build with the help of @fifonix and if it works, enable vmware + aarch64 in the pipeline
<@spresti:fedora.im>
17:40:31
!agreed: "we will test out an aarch64 vmware build with the help of @fifonix and if it works, enable vmware + aarch64 in the pipeline"
<@spresti:fedora.im>
17:40:35
idk
<@spresti:fedora.im>
17:40:44
zodbot!!!
<@jlebon:fedora.im>
17:40:52
!agreed we will test out an aarch64 vmware build with the help of @fifonix and if it works, enable vmware + aarch64 in the pipeline
<@jlebon:fedora.im>
17:41:06
and on that note, have to drop. thanks all and thanks jbtrystram for running!
<@dustymabe:matrix.org>
17:41:06
maybe the `:` is throwing it off?
<@spresti:fedora.im>
17:41:08
oh ok
<@spresti:fedora.im>
17:41:25
yeah must be
<@siosm:matrix.org>
17:41:33
yeah, likely the ":"
<@spresti:fedora.im>
17:41:35
Though curiously with other commands it does not
<@jbtrystram:matrix.org>
17:41:40
!topic Open Floor
<@dustymabe:matrix.org>
17:41:42
or maybe zobbot died, don't know
<@siosm:matrix.org>
17:41:48
Let's do 5 min open floor, we're late
<@spresti:fedora.im>
17:41:57
yah
<@siosm:matrix.org>
17:42:22
Any topics for open floor?
<@dustymabe:matrix.org>
17:43:17
Nothing from my side.. other than we should be enabling our `branched` stream soon
<@fifofonix:matrix.org>
17:46:04
Only an observation: the last several updates have been completely seamless from my point-of-view which is the way obvs (that's a thank you). I only mention because there were a couple of months where I was getting hanging shutdowns/upgrades that occurred on 5% of machines say (often looking like SMB-related causes). That's all gone magically now.
<@fifofonix:matrix.org>
17:46:26
Only an observation: the last several updates have been completely seamless from my point-of-view which is the way obvs (that's a thank you). I only mention because there were a couple of months where I was getting hanging shutdowns/upgrades that occurred on 5% of machines say (often looking like timing-related SMB-related causes). That's all gone magically now.
<@dustymabe:matrix.org>
17:47:50
let's close it out
<@jbtrystram:matrix.org>
17:48:00
!endmeeting