<@humaton:fedora.im>
19:35:46
!startmeeting FESCO (2024-02-19)
<@meetbot:fedora.im>
19:35:47
Meeting started at 2024-02-19 19:35:46 UTC
<@meetbot:fedora.im>
19:35:47
The Meeting name is 'FESCO (2024-02-19)'
<@humaton:fedora.im>
19:35:53
!meetingname fesco
<@humaton:fedora.im>
19:36:01
Chairs: @conan_kudo:matrix.org, @ngompa:fedora.im, @nirik:matrix.scrye.com, @humaton:fedora.im, @zbyszek:fedora.im, @sgallagh:fedora.im, @jistone:fedora.im, @dcantrell:fedora.im, @mhayden:fedora.im, @tstellar:fedora.im
<@humaton:fedora.im>
19:36:07
!topic Init Process
<@dcantrell:fedora.im>
19:36:37
!hello
<@zodbot:fedora.im>
19:36:38
David Cantrell (dcantrell) - he / him / his
<@conan_kudo:matrix.org>
19:36:44
!hi
<@zodbot:fedora.im>
19:36:46
Neal Gompa (ngompa) - he / him / his
<@humaton:fedora.im>
19:36:50
!hi
<@zodbot:fedora.im>
19:36:51
Tomáš Hrčka (humaton) - he / him / his
<@jkonecny:fedora.im>
19:37:48
!hi
<@zodbot:fedora.im>
19:37:49
Jiří Konečný (jkonecny)
<@jkonecny:fedora.im>
19:39:36
I'll try to be available but it will be harder for me
<@humaton:fedora.im>
19:40:26
we don't have quorum yet, will give it few more minutes
<@zbyszek:fedora.im>
19:41:24
I'm almost here. Just need to walk up the stairs ;)
<@adamwill:fedora.im>
19:45:33
nirik's username says he's on PTO
<@humaton:fedora.im>
19:46:21
yup he is but we will have quorum once zbyszek is home
<@adamwill:fedora.im>
19:46:38
oh, sorry dcantrell, i didn't see you registered her and pinged you elsewhere
<@zbyszek:fedora.im>
19:46:58
I'm home. Sorry.
<@dcantrell:fedora.im>
19:47:30
no worries, I just responded elsewhere
<@humaton:fedora.im>
19:47:34
so we have quorum if I count correctly
<@sgallagh:fedora.im>
19:48:09
I'm also on PTO, but I can spare a few minutes
<@humaton:fedora.im>
19:48:48
!topic 3158 Change: Arm Minimal Image OS Build
<@humaton:fedora.im>
19:48:57
!fesco 3158
<@zodbot:fedora.im>
19:48:57
**fesco #3158** (https://pagure.io/fesco/issue/3158):**Change: Arm Minimal Image OS Build**
● **Opened:** 3 weeks ago by amoloney
● **Last Updated:** 5 hours ago
● **Assignee:** pbrobinson
<@zbyszek:fedora.im>
19:49:22
A bunch of people voted, but it wasn't clear if there still are issues.
<@zbyszek:fedora.im>
19:49:28
Or questions…
<@sgallagh:fedora.im>
19:51:33
I'm not sure what there is left to discuss. As far as I know 1) Peter responded with the information requested and 2) no one has voted -1
<@conan_kudo:matrix.org>
19:52:13
I have held back my vote because I didn't want to appear antagonistic.
<@conan_kudo:matrix.org>
19:52:48
But as-is, with no fedora-blueprints repo with _some kind_ of description of what the ARM image even _is_, I seriously hesitate to vote in favor of it
<@conan_kudo:matrix.org>
19:53:02
I don't want a release blocking image that I have no idea how it's made
<@humaton:fedora.im>
19:53:13
this
<@conan_kudo:matrix.org>
19:53:15
or what defines the content included
<@conan_kudo:matrix.org>
19:53:29
if forced to vote now, I will vote -1
<@conan_kudo:matrix.org>
19:53:51
but I have deliberately held back my vote because I was hoping this would be resolved before we got here
<@humaton:fedora.im>
19:54:12
I am reading through Peters response and this will be mess for next release process, we need to have clearly defined place where the blueprint is
<@humaton:fedora.im>
19:54:25
so releng can check/ modify the iimages as needed
<@adamwill:fedora.im>
19:54:25
not a fesco member, but representing quality, i'd be concerned about further delays to voting or implementing this. we're one week from beta freeze and this is a complete change in how a release-blocking image is built
<@conan_kudo:matrix.org>
19:54:45
fwiw, we have the same problem with the workstation osbuild image too, but because it's nonblocking, I'm... less concerned
<@zbyszek:fedora.im>
19:54:53
Oh, I thought this is for F41.
<@conan_kudo:matrix.org>
19:55:00
no, this is being pushed for F40
<@adamwill:fedora.im>
19:55:03
it says "Targeted release: Fedora Linux 40"
<@zbyszek:fedora.im>
19:55:30
Hmm, that is concerning. I would expect the blueprints to be essentially ready at this point, if this is to be implemented for F41.
<@zbyszek:fedora.im>
19:55:48
Hmm, that is concerning. I would expect the blueprints to be essentially ready at this point, if this is to be implemented for <del>F41.</del> F40.
<@zbyszek:fedora.im>
19:55:51
We can't really not have those for Beta.
<@zbyszek:fedora.im>
19:56:35
And the same goes for changes to Pungi. I would expect the pull requests to be under review by now.
<@conan_kudo:matrix.org>
19:57:56
My chief concern has been I have no idea what defines or controls any of the osbuild-based artifacts
<@sgallagh:fedora.im>
19:58:01
zbyszek: To be fair, the delay is at least largely our fault in not moving forward on this tikcet
<@conan_kudo:matrix.org>
19:58:07
today, we have two: Fedora IoT and non-blocking Workstation
<@conan_kudo:matrix.org>
19:58:24
I don't really want a third with Fedora ARM
<@davide:cavalca.name>
19:59:06
is there something specific about osbuild that makes it hard to publish the blueprints for these?
<@davide:cavalca.name>
19:59:21
like, if we're building them the blueprints have to be _somewhere_ already...
<@conan_kudo:matrix.org>
19:59:29
I don't know.
<@smooge:fedora.im>
19:59:48
there shouldn't be
<@smooge:fedora.im>
20:00:14
that said, I mainly use osbuild-mpp for building images
<@obudai:fedora.im>
20:00:27
AFAIK the minimal build is just an empty blueprint.
<@conan_kudo:matrix.org>
20:00:39
When davdunc and I investigated it for Fedora Cloud, the answer we got was that blueprints cannot fully define images nor can they fully control the process for building them. But they do have _some_ information regardless.
<@sgallagh:fedora.im>
20:01:09
So we have no examples of a useful blueprint, but we want to make it a prerequisite for this Change?
<@smooge:fedora.im>
20:01:46
I was thinking it was more like 'we have no idea of what work is needed to make this change happen'
<@conan_kudo:matrix.org>
20:01:54
Yes.
<@conan_kudo:matrix.org>
20:02:02
Also, I have no idea what it looks like when something breaks.
<@zbyszek:fedora.im>
20:02:05
And also, we have no idea how this is going to look when implemented.
<@obudai:fedora.im>
20:02:50
Hmm, isn't the IoT SIG already doing test builds in Koji?
<@zbyszek:fedora.im>
20:02:51
And, also, where will all the config live and who will have access/control.
<@humaton:fedora.im>
20:02:53
+ there is not much experience with osbuild in releng
<@zbyszek:fedora.im>
20:03:20
Link?
<@sgallagh:fedora.im>
20:03:27
zbyszek: When I talked with Peter, he indicated that documenting that was intended to be part of the deliverable
<@zbyszek:fedora.im>
20:04:23
Yes, documenting this is good. But in general, for Changes we approve, I think we should have at least an outline idea what the answers to such questions are.
<@zbyszek:fedora.im>
20:04:35
I.e. before we approve it.
<@humaton:fedora.im>
20:05:38
we are over 15 minutes on the topic
<@obudai:fedora.im>
20:05:54
https://koji.fedoraproject.org/koji/taskinfo?taskID=113239754
<@conan_kudo:matrix.org>
20:06:20
that task has no pointer to source input definitions
<@zbyszek:fedora.im>
20:06:24
Thanks obudai, this is useful.
<@conan_kudo:matrix.org>
20:07:41
anyway, I'm comfortable being the sole -1, but I am uncomfortable with having image builds where we don't have source definitions for
<@zbyszek:fedora.im>
20:08:23
Hmm, so how does it work without a source definition?
<@humaton:fedora.im>
20:08:25
Conan Kudo: I am -1 on this as well
<@davide:cavalca.name>
20:08:29
is the expectations that users should be able to recreate image build artifacts?
<@conan_kudo:matrix.org>
20:08:36
yes
<@davide:cavalca.name>
20:08:46
if we don't have source definitions that seems difficult, but I don't know if it's an actual requirement
<@adamwill:fedora.im>
20:08:53
zbyszek: aiui, the definitions are kind of baked into osbuild, at this point
<@conan_kudo:matrix.org>
20:08:54
but also that if we have to dev/troubleshoot images, reproducing them is important
<@adamwill:fedora.im>
20:09:00
e.g. i *suspect* the 'definition' for that task was, more or less, https://github.com/osbuild/osbuild/blob/43c83c01e6150a52cf8c1da6bc4c01bc9a7ba835/test/data/manifests/fedora-ostree-bootiso.mpp.yaml#L27
<@adamwill:fedora.im>
20:10:09
i think the problem Conan Kudo is identifying is the way this stuff is baked into the build tool means we don't really know what version of the manifest was used , the images aren't reproducible without knowing what state the image builder instance was in when the image was built
<@humaton:fedora.im>
20:10:27
do we have more to discuss on this topic or are we going to vote?
<@zbyszek:fedora.im>
20:10:32
That also seems like a really really bad design.
<@conan_kudo:matrix.org>
20:10:55
Yes. More or less.
<@zbyszek:fedora.im>
20:11:13
So I think I'd like to withdraw my +1 vote for now. I thought I generally understand what this is about, but now I feel like the description doesn't have nearly enough details.
<@conan_kudo:matrix.org>
20:11:26
As it stands, -1 for me
<@adamwill:fedora.im>
20:11:34
(and, of course, fedora releng has no commit access to osbuild repos and doesn't control its deployment, so is reliant on other parties to fix any problems)
<@nhanlon:beeper.com>
20:11:57
fwiw, (again, hi, lurking...) -- I did find [this](https://github.com/osbuild/fedora-blueprints) repository -- not sure if that is known or not.. just researching myself
<@humaton:fedora.im>
20:11:59
that is basicaly base of my -1
<@dcantrell:fedora.im>
20:12:30
I was going to vote 0, but I'll join -1 based on this conversation
<@adamwill:fedora.im>
20:13:52
e.g. i _suspect_ the 'definition' for that task was, more or less, https://github.com/osbuild/osbuild/blob/43c83c01e6150a52cf8c1da6bc4c01bc9a7ba835/test/data/manifests/fedora-ostree-bootiso.mpp.yaml#L27
edit: actually i think that's test data, but the overall point remains. i can't actually find where the 'real' iot manifest lives, which rather illustrates the problem.
<@sgallagh:fedora.im>
20:13:54
Before voting -1, could you enumerate what *precisely* you want to see added to the proposal?
<@dcantrell:fedora.im>
20:14:54
gummi bears
<@conan_kudo:matrix.org>
20:15:14
For me to change to +1, I want a pagure.io/fedora-blueprints with the blueprint file for this image that can be used to orchestrate this build in Koji
<@zodbot:fedora.im>
20:15:24
neil gave a cookie to dcantrell. They now have 12 cookies, 2 of which were obtained in the Fedora 39 release cycle
<@conan_kudo:matrix.org>
20:15:43
that _needs_ to work so that we have a process around the image similar to what we have elsewhere
<@humaton:fedora.im>
20:15:53
For me it is documentation for Fedora Release Engineering to be able to replicate/modify the contents of resulting artifact
<@adamwill:fedora.im>
20:15:53
e.g. i _suspect_ the 'definition' for that task was, more or less, https://github.com/osbuild/osbuild/blob/43c83c01e6150a52cf8c1da6bc4c01bc9a7ba835/test/data/manifests/fedora-ostree-bootiso.mpp.yaml#L27
edit: actually i think that's test data, but the overall point remains. i can't actually find where the 'real' iot manifest lives, which rather illustrates the problem. possibly it's part of https://github.com/osbuild/images .
<@sgallagh:fedora.im>
20:16:37
Conan Kudo: Is it necessary to dictate the technology or is jednorozec 's statement sufficient?
<@sgallagh:fedora.im>
20:16:57
If we add "to releng's satisfaction" inthere
<@sgallagh:fedora.im>
20:17:03
If we add "to releng's satisfaction" in there
<@conan_kudo:matrix.org>
20:17:06
I am using specific terms in osbuild parlance
<@conan_kudo:matrix.org>
20:17:35
if we can't even use the osbuild way to define images to run fedora images, we have a problem
<@conan_kudo:matrix.org>
20:18:15
probably `fedora-osbuild-blueprints` as a repo name
<@conan_kudo:matrix.org>
20:18:18
I don't really care
<@conan_kudo:matrix.org>
20:18:36
but I expect that jednorozec and my statements don't conflict, mine is just more specific than his
<@adamwill:fedora.im>
20:19:54
i'm not sure blueprints will necessarily achieve the desired effect? it's interesting to me that https://github.com/osbuild/fedora-blueprints states "Generally the blueprints (found in blueprints/) are much shorter than their kickstart counterparts. That is because in osbuild-composer a lot of work is handled by the image type."
<@adamwill:fedora.im>
20:20:24
which implies that even with a blueprint-driven image, some of the work of 'defining the image' is happening elsewhere
<@adamwill:fedora.im>
20:21:36
and e.g. https://github.com/osbuild/fedora-blueprints/blob/main/blueprints/workstation-live-iso.toml has a comment that says "These packages are installed upon the 'base' fedora as defined in `osbuild-composer`."
<@conan_kudo:matrix.org>
20:22:12
that's discouraging
<@jkonecny:fedora.im>
20:22:36
I think it's defined here: https://github.com/osbuild/images but obudai will know much better than me
<@adamwill:fedora.im>
20:22:42
and e.g. https://github.com/osbuild/fedora-blueprints/blob/main/blueprints/workstation-live-iso.toml has a comment that says "These packages are installed upon the 'base' fedora as defined in `osbuild-composer`.", which I believe refers to https://github.com/osbuild/osbuild-composer . so again we wind up with a definition of "fedora" which is outside of fedora's direct control, I think?
<@nhanlon:beeper.com>
20:23:23
that was my read as well
<@dcantrell:fedora.im>
20:25:25
this is what lmc didn't do. input was just a kickstart file. I never understood the obsession with osbuild and replacing a DSL that was established and worked, but whatever
<@adamwill:fedora.im>
20:25:56
i guess to a degree this kinda exists with koji; koji does some 'business logic' and there's no rule that says fedora releng can commit to koji. but we at least control fedora's koji deployment and can patch it at will
<@zbyszek:fedora.im>
20:26:01
Stephen Gallagher: To answer your question: I would like to understand how the workflow is supposed to work, and what parts are needed, and who can modify the config (assuming that there's a separate config from the code). jednorozec's request for "documentation for Fedora Release Engineering to be able to replicate/modify the contents of resulting artifact" would probably answer those questions.
<@adamwill:fedora.im>
20:26:32
i guess to a degree this kinda exists with koji; koji does some 'business logic' and there's no rule that says fedora releng can commit to the upstream koji project. but we at least control fedora's koji deployment and can patch it at will
<@humaton:fedora.im>
20:26:48
So I am not sure what to do now we are already 50 mins on this topic. And there are obviously some more questions we need to get answered
<@humaton:fedora.im>
20:26:58
This is the first time I am running this meeting
<@conan_kudo:matrix.org>
20:27:24
this is fine
<@sgallagh:fedora.im>
20:27:27
jednorozec: Gather a list of the required information we need to make a decision, then punt for a week.
<@obudai:fedora.im>
20:27:49
I'm concerned by the requirement to replicate the build... That's already possible, install osbuild-composer, build an iot-bootable-contianer image with an empty blueprint. You get what koji would build.
<@humaton:fedora.im>
20:28:26
Is there a documentation page that somebody with minimal experience can folllow and build stuff?
<@sgallagh:fedora.im>
20:28:26
That being said, at this point "punt for a week" is effectively a deferral, I suppose.
<@sgallagh:fedora.im>
20:28:31
Since we'll be at Beta Freeze
<@adamwill:fedora.im>
20:28:43
right. i really wouldn't want this to land during freeze.
<@adamwill:fedora.im>
20:29:44
who deploys and controls the osbuild instance used for those iot builds? do we know if this proposal involves using that instance, or the one that seems to behind a red hat firewall which is used for the non-blocking workstation live osbuild builds?
<@zbyszek:fedora.im>
20:32:12
Can we build the F40 images with the old imagefactory pipeline? I.e. if we don't approve this, can we still put out F40.
<@zbyszek:fedora.im>
20:32:14
Can we build the F40 images with the old imagefactory pipeline? I.e. if we don't approve this, can we still put out F40?
<@conan_kudo:matrix.org>
20:32:52
yes
<@conan_kudo:matrix.org>
20:33:27
imagefactory is still around for F40, the idea is it'll be gone in F41 and everyone needs to come up with a replacement (either lorax, kiwi, or osbuild) for F41
<@obudai:fedora.im>
20:33:56
huh? I don't know of any IB stuff for Fedora behind the firewall? But yeah, the Image Builder team is currently running a part of the infrastructure.
<@obudai:fedora.im>
20:34:08
Nah, you cannot use ImageFactory for ostree native stuff.
<@adamwill:fedora.im>
20:34:35
obudai: sorry if i'm wrong there, i'm finding it hard to know exactly what image builder instance(s) we have
<@sgallagh:fedora.im>
20:34:48
Please expand on this?
<@adamwill:fedora.im>
20:35:15
i was looking at https://koji.fedoraproject.org/koji/taskinfo?taskID=113734470 , where an osbuild workstation live failed because of problems with sso.redhat.com
<@sgallagh:fedora.im>
20:35:30
Are you saying "No, we can't ship F40 using ImageFactory because of the container-native stuff"?
<@obudai:fedora.im>
20:36:46
Ahhh, this is the minimal image!
<@obudai:fedora.im>
20:36:48
Sorry!
<@obudai:fedora.im>
20:37:01
I don't know about that.
<@humaton:fedora.im>
20:37:19
ok
<@humaton:fedora.im>
20:37:32
!agreed punt this topic for a week
<@jkonecny:fedora.im>
20:37:33
if you are talking about container native usage for Atomic Desktops. There were already discussion to use bootc-osbuild for that because it would be probably easier than implementing support for Lorax
<@humaton:fedora.im>
20:37:51
I wrote comment to the original ticket with some questions
<@humaton:fedora.im>
20:37:58
will add more points after the meeting
<@humaton:fedora.im>
20:38:07
!topic 3169 Weigh in on installer storage setup issue
<@humaton:fedora.im>
20:38:20
!fesco 3169
<@zodbot:fedora.im>
20:38:21
**fesco #3169** (https://pagure.io/fesco/issue/3169):**Weigh in on installer storage setup issue**
● **Opened:** 6 days ago by sgallagh
● **Last Updated:** an hour ago
● **Assignee:** Not Assigned
<@zbyszek:fedora.im>
20:38:55
Everyone refresh, if you have the ticket open, there has been a bunch of comments within the last few hours.
<@dcantrell:fedora.im>
20:39:02
now for the easier meeting item :)
<@zbyszek:fedora.im>
20:40:26
At least here, we know what is happening and the development plans are rather clear. We just don't like what is happening and disagree with the development plans.
<@jkonecny:fedora.im>
20:41:09
sorry added one more comment just now 😄 -- just confirmation
<@sgallagh:fedora.im>
20:41:36
Half-serious question: can we just make it hard to find the custom partitioning option in the installer, buried behind "This will eat your data" and possibly a "Beware of leopard" warning click-through?
<@jkonecny:fedora.im>
20:41:55
we already doing that
<@jkonecny:fedora.im>
20:42:11
if you click on the button you have a popup with all the warnings and red letters
<@jkonecny:fedora.im>
20:42:36
and one more warning sign on the top of the Cockpit Storage screen whole time
<@dcantrell:fedora.im>
20:42:57
I will say one of the biggest improvements we made to anaconda in the past was modeling storage changes before making users commit the changes to the system. We received nothing but positive feedback on that aspect. To undo that would be a huge backslide, IMHO.
<@zodbot:fedora.im>
20:43:14
sgallagh gave a cookie to dcantrell. They now have 13 cookies, 3 of which were obtained in the Fedora 39 release cycle
<@conan_kudo:matrix.org>
20:43:26
I have a very nasty feeling we'll be roasted by reviewers once that's noticed too.
<@zodbot:fedora.im>
20:43:27
humaton gave a cookie to dcantrell. They now have 14 cookies, 4 of which were obtained in the Fedora 39 release cycle
<@sgallagh:fedora.im>
20:43:49
The reviewers aren't my first concern... but they're definitely in the top three.
<@zodbot:fedora.im>
20:43:51
decathorpe gave a cookie to dcantrell. They now have 15 cookies, 5 of which were obtained in the Fedora 39 release cycle
<@jkonecny:fedora.im>
20:44:13
dcantrell: I'm surprised to hear that my feedback was that people are not happy about that much... but yeah, it was mostly about it's too complicated (which honestly is - yeah Linux storage is super complicated)
<@conan_kudo:matrix.org>
20:44:25
users trying to install fedora is my first, reviewers are my second, me is third
<@conan_kudo:matrix.org>
20:44:37
I will easily accidentally break things with immediate apply partitioning
<@sgallagh:fedora.im>
20:44:47
My biggest concern is the fact that many people installing Fedora tend to fall into Dunning-Kruger when faced with "basic vs. advanced" choices.
<@dcantrell:fedora.im>
20:45:03
it's true, storage configuration is complicated. that was a constant balancing act of how do you actively maintain a fast moving installer for something like Fedora but also keep around the functionality needed for products like RHEL. we didn't want two installers
<@cmurf:fedora.im>
20:45:10
design it so the reviewers can't find it? (this is a bad joke, therefore laugh)
<@zbyszek:fedora.im>
20:45:12
The way I see the problem is: ~50% of users will try some for of non-automatic storage configuration. (This incl. fully manual setups and automatic-setup-with-adjustments.) And the interface we have right now for this is bad. Doing any kind of setup with more than two partitions is hard to do correctly, slow, and annoying.
<@sgallagh:fedora.im>
20:45:15
Conan Kudo: Yeah, same :)
<@adamwill:fedora.im>
20:45:21
if you give me about ten minutes i can post some screenshots
<@dcantrell:fedora.im>
20:45:24
the most common use cases for storage were the single disk laptop user and then the RHEL customer with 100000 LUNs
<@adamwill:fedora.im>
20:45:25
since the UI *just* changed again today
<@conan_kudo:matrix.org>
20:45:39
I guess we're operating at the speed of webdev
<@zodbot:fedora.im>
20:45:43
jkonecny gave a cookie to dcantrell. They now have 16 cookies, 6 of which were obtained in the Fedora 39 release cycle
<@adamwill:fedora.im>
20:45:44
to see the current state , https://openqa.fedoraproject.org/tests/2427050/asset/iso/02427050-Fedora-Workstation-Live-x86_64-FEDORA-2024-273de1817d.iso should work
<@cmurf:fedora.im>
20:45:45
My recollection of the installer refresh ~10 years ago, is the commitment to user data, and a very clear and consistent threshold for reversibility: begin installation button. Reverting from this seems awkward.
<@conan_kudo:matrix.org>
20:46:19
yes, the idea was that nothing is committed until you hit "begin installation"
<@conan_kudo:matrix.org>
20:46:33
at the time, no other installer did that, it was a huge innovation
<@dcantrell:fedora.im>
20:46:42
we've basically spent a decade training users to trust that
<@dcantrell:fedora.im>
20:47:01
it would be bad for a long time user's muscle memory lead to loss of /home
<@adamwill:fedora.im>
20:47:05
we probably need to be realistic about the degree to which fesco can dictate the developers' design choices here, though
<@adamwill:fedora.im>
20:47:17
and acknowledge the constraints that are in operation
<@sgallagh:fedora.im>
20:47:33
Let me be perfectly clear: I would rather see us ship with *only guided partitioning* than to ship with "instant-apply" custom partitioning.
<@sgallagh:fedora.im>
20:47:38
Can I be any clearer?
<@jkonecny:fedora.im>
20:47:49
Want to make you obvious that Installer team is not able to maintain reasonably even the current custom partitioning nor create a new one
<@cmurf:fedora.im>
20:47:54
yeah i was wondering about the consequences of shipping with only guided...
<@jkonecny:fedora.im>
20:48:01
the current one is lacking
<@jkonecny:fedora.im>
20:48:10
VDO nor Stratis are supported
<@jkonecny:fedora.im>
20:48:27
and we were not able to get to that at all in the last few years
<@jkonecny:fedora.im>
20:48:36
we just don't have capacity to keep that
<@jkonecny:fedora.im>
20:48:58
when the current custom partitioning screen was created the installer team had about 10 members now it's about 3
<@sgallagh:fedora.im>
20:49:53
Proposal: Graphical installer should only ship with guided partitioning (possibly with a limited selection of known-common configurations). Custom partitioning must be done manually using other tools prior to launching the installer or limited to kickstart-based installs.
<@jkonecny:fedora.im>
20:49:59
cmurf: only guided partitioning could be used but you would kill the GIS session basically
<@adamwill:fedora.im>
20:50:45
Stephen Gallagher: so the challenge with 'custom partitioning must be done manually prior to launching the installer' is, to a rough approximation, *nobody* actually knows what partitions they have to create
<@conan_kudo:matrix.org>
20:50:53
Stephen Gallagher: note that this would guarantee that Fedora KDE will stick with the gtk-based UI for the foreseeable future
<@adamwill:fedora.im>
20:50:55
nobody knows or remembers about biosboot partitions or EFI system partitions
<@jkonecny:fedora.im>
20:50:56
also what would be the benefit of it? To me the question is still more about make it obvious to users that they are not blocked on this tool nor this is part of Anaconda workflow -- it's just an external tool they can use
<@sgallagh:fedora.im>
20:51:15
adamw: Which is why the graphical environment should only present the guided mode :)
<@davide:cavalca.name>
20:51:36
probably a dumb idea: can we ship gparted in the ISO and tell users to run that before the installer if they want custom partitioning?
<@dcantrell:fedora.im>
20:51:45
haha
<@dcantrell:fedora.im>
20:51:47
come on
<@adamwill:fedora.im>
20:51:54
Davide Cavalca: the problematic workflow is the one jkonency refers to as "g-i-s"
<@conan_kudo:matrix.org>
20:52:12
I mean... if we did that, we might as well tell people to use blivet-gui
<@conan_kudo:matrix.org>
20:52:21
because unlike gparted, blivet-gui actually supports everything
<@jkonecny:fedora.im>
20:52:23
Davide Cavalca: also in the future it will be the same situation with network installations
<@jkonecny:fedora.im>
20:52:36
and boot.iso
<@adamwill:fedora.im>
20:52:40
this is where you boot the live image, go through two pages of g-i-s to set language and keyboard layout, then you get two choices
<@adamwill:fedora.im>
20:53:01
if you hit "Install to Disk..." there, you are put in a minimal environment running anaconda, there is no 'desktop'
<@adamwill:fedora.im>
20:53:26
on this flow there really isn't an opportunity to launch a custom partitioning tool other than whatever opportunity anaconda gives you. unless we crowbarred one into that g-i-s screen, or something.
<@jkonecny:fedora.im>
20:53:30
blivet-gui have one active developer (who has this as his pet project) and one blocker bug
<@jkonecny:fedora.im>
20:54:25
just for the record - this Gnome Initial Setup workflow was requested by Workstation SIG
<@adamwill:fedora.im>
20:54:32
screenshots, hot off the press, with the new anaconda-webui as of a couple of hours ago: this is the main screen you see immediately after the screen above, if you clikc "Install to Disk..."
<@jkonecny:fedora.im>
20:54:34
wasn't part of the origin proposal
<@adamwill:fedora.im>
20:55:01
those are all your partitioning choices. The "Modify storage" text launches the cockpit-based custom flow.
<@cmurf:fedora.im>
20:55:03
I've missed the leap from guided path doesn't support GIS - so I'm running into a brickwall conclusion that guided only is untenable? is that correct?
<@adamwill:fedora.im>
20:55:18
that looks like this
<@conan_kudo:matrix.org>
20:56:10
:(
<@conan_kudo:matrix.org>
20:56:15
so it's not substantially different
<@adamwill:fedora.im>
20:56:19
the 'delete' option for any existing device is red, and clicking it shows this:
<@jkonecny:fedora.im>
20:56:41
cmurf: no - guided is usable everywhere, the issue is that Workstation SIG requested to have solution for a few use-cases which are not yet covered by that. IIRC they explicitly wanted to have a custom partitioning replacement Conan Kudo would maybe remember better
<@conan_kudo:matrix.org>
20:57:07
The biggest use-case still missing was preserving users
<@conan_kudo:matrix.org>
20:57:11
and user data
<@conan_kudo:matrix.org>
20:57:20
that is not supported in any guided workflow, and requires custom partitioning
<@jkonecny:fedora.im>
20:57:30
you can do that with Mount point assignment
<@cmurf:fedora.im>
20:57:45
OK I think the live action dialogs needs to include "immediate" to convey this is permanent life altering event is actually going to happen right now
<@humaton:fedora.im>
20:57:49
I will destroy number of partitions with this new approach
<@jkonecny:fedora.im>
20:58:14
jednorozec: I wonder why would you do that?
<@sgallagh:fedora.im>
20:58:29
That's a terrible UX for that. Probably we should add a lot more explanation below that option
<@adamwill:fedora.im>
20:58:46
hum, and i apparently failed at attempting to reformat the existing btrfs partition and use it as / .
<@humaton:fedora.im>
20:58:54
The text mentioning the changes are immediate is just not visible enough for me
<@humaton:fedora.im>
20:59:43
complicatedly missed it on the screen just seen it in the screenshot by adam.
<@jkonecny:fedora.im>
20:59:46
Unfortunately BTRFS support in Cockpit Storage is young but they are working on that heavily to stabilize it based on the feedback
<@jkonecny:fedora.im>
21:00:02
jednorozec: that is definitely something we can improve
<@cmurf:fedora.im>
21:00:10
i thought we'd discussed that `/home` and user preservation needs to be an option in guided path? like, the idea is to optionally do more things in guided so that users don't have to resort to custom partitioning and the ensuing trouble
<@jkonecny:fedora.im>
21:00:40
cmurf: still on the plan but unfortunately we wan't able to get to that
<@sgallagh:fedora.im>
21:00:42
cmurf: Apparently, it's there as "assign mount points"... it's just REALLY not clear that's what it's for
<@conan_kudo:matrix.org>
21:00:45
we did. they said they can't do it and we told them we need custom partitioning for that then
<@adamwill:fedora.im>
21:00:47
i personally am a bit confused about the "guided" terminology. what are we considering to be part of "guided", here?
<@conan_kudo:matrix.org>
21:01:21
because blowing away volumes and keeping others and importing users is something that every other installer can do
<@conan_kudo:matrix.org>
21:01:29
and we want that for ours too
<@jkonecny:fedora.im>
21:02:03
we never had that in the past, but ok
<@humaton:fedora.im>
21:02:08
I have to run AFK for a while can one of you write the conclusion and close the meeting?
<@zbyszek:fedora.im>
21:02:29
jednorozec: yes, thanks for doing it so far.
<@conan_kudo:matrix.org>
21:02:41
we had seriously hoped the new work on Anaconda was going to give us that feature, that's why Workstation WG asked for it early on
<@jkonecny:fedora.im>
21:02:42
yeah, it is a good requirement - I don't argue about that
<@conan_kudo:matrix.org>
21:03:04
it was a complaint we got from users in the past
<@cmurf:fedora.im>
21:03:16
ok i think the big issue though is that the cockpit UI change landing when it did and inadvertently was not communicated, is the bigger issue - right? like there's a metric ton or two (weeks) of work on the QA side that was done and then thrown out as a result of the changes - which i guess might also still be continuing
<@cmurf:fedora.im>
21:03:34
so the feature change isn't really stable? is that fair?
<@conan_kudo:matrix.org>
21:03:39
anyway, that's beside the point
<@adamwill:fedora.im>
21:03:44
cmurf: eh, not so much work that was done and thrown out as work that is suddenly required that we were not expecting
<@jkonecny:fedora.im>
21:03:46
however, we don't want to create everything on backstage and then come to you with -- everything changed everything is implemented and we would then get this discussion but with much more topics to discuss
<@sgallagh:fedora.im>
21:04:10
cmurf: That's not everything. It's also about the fact that had this been communicated earlier, we probably would have said "no"
<@cmurf:fedora.im>
21:04:19
ok good distinction
<@conan_kudo:matrix.org>
21:04:25
exactly
<@jkonecny:fedora.im>
21:04:40
cmurf: no more changes to the UX are planned until they are requested - currently we should do only stabilization
<@sgallagh:fedora.im>
21:04:46
Because the custom partitioning flow represents a significant regression that we WILL have problems with
<@jkonecny:fedora.im>
21:05:33
Stephen Gallagher: we are still getting to loop, installer team don't have capacity to provide you other solution
<@adamwill:fedora.im>
21:05:58
the facts are: we (quality team) did not realize that the cockpit-storage based flow would be appearing for F40 until about two weeks ago. I don't believe FESCo was aware either. the first anaconda-webui package with the change appeared on 2024-02-07. the first compose with the change appeared on 2024-02-10. beta branching took up a lot of time last week, and there is active development still happening on this stuff, which complicates things. beta freeze is 2024-02-27. the realistic 'last day for images' for the current beta target date is 2024-03-05 or 2024-03-06.
<@sgallagh:fedora.im>
21:06:03
jkonecny: My current proposal is that if we're going to regress anyway, we should just drop custom ENTIRELY and only provide the safe approach
<@conan_kudo:matrix.org>
21:06:24
Well, actually, the other option is to ask Workstation WG if this is worth it for F40
<@adamwill:fedora.im>
21:06:35
this new flow requires revisions to the release criteria, wiki test cases, validation matrices and (ideally) openQA automated tests
<@conan_kudo:matrix.org>
21:06:42
they are the _only_ variant shipping this right now, so we can ask if they are okay with such a regression
<@adamwill:fedora.im>
21:06:46
we have to make those changes, run all the tests, file bugs, and work through the fix/retest cycle
<@cmurf:fedora.im>
21:07:03
OK given the custom path integration with Workstation GIS, I don't think dropping custom is actually an option
<@sgallagh:fedora.im>
21:07:46
adamw: OK, so what is the request from QA, here? Are you asking for a schedule delay?
<@adamwill:fedora.im>
21:07:48
we are already in the process of trying to do this. on the whole, though, this timeframe places the beta and final releases at fairly high schedule risk.
<@jkonecny:fedora.im>
21:07:56
I'm sorry about that adamw you know that it wasn't fault solely on our side. But we honestly forgot about this, on the other hand we had a presentation about his on F39 release party - it wasn't secret from us just not advertised enough
<@jkonecny:fedora.im>
21:08:22
Fedora QE is invited to our periodic meetings to cooperate on Web UI, unfortunately not joining ☹️
<@conan_kudo:matrix.org>
21:08:24
the Workstation WG has their meeting tomorrow, so we should ask them to consider whether they want this for F40 or punt to F41 to give time to deal with the fallout
<@jkonecny:fedora.im>
21:08:36
but I hope that will improve
<@adamwill:fedora.im>
21:08:38
Stephen Gallagher: so there's a couple of things. the key one is the criterion. do we change the criterion to be OK with instant-apply.
<@adamwill:fedora.im>
21:09:30
then there's the whole issue of this cockpit-storage workflow being a major revision to an accepted Change, which was not communicated to fesco or quality, and which is landing late. does fesco want to accept the risk involved in attempting to push forwards with this change and land it in beta?
<@adamwill:fedora.im>
21:09:42
if so, we will do our best to get the tests revised and run and all the bugs filed
<@zbyszek:fedora.im>
21:09:51
How was it in F39? If you had an existing /home, did we support keeping that? And what if /home was a volume on btrfs?
<@conan_kudo:matrix.org>
21:10:11
you could blow away only the root subvolume and reuse the home subvolume
<@conan_kudo:matrix.org>
21:10:16
it's been that way since Fedora 18
<@zbyszek:fedora.im>
21:10:33
Thanks, that's what I thought. So it seems we completely lost this feature.
<@adamwill:fedora.im>
21:10:36
zbyszek: so in gtkui, without touching a custom flow, you can resize existing partitions (though this is apparently less useful than it used to be with windows due to bitlocker), and selectively delete existing devices
<@adamwill:fedora.im>
21:10:49
assigning mount points to existing devices requires the use of one of the custom flows
<@adamwill:fedora.im>
21:11:04
no, that is not right
<@cmurf:fedora.im>
21:11:24
well you have the option to delete or keep the old root, it's required to create a new root for installation on btrfs; and it's also an option to reuse or delete old home, and create a new home (or not, in which case it's a directory)
<@adamwill:fedora.im>
21:11:29
you can only do that in a custom flow on gtkui. and you should still be able to do it in custom flow on webui+cockpit (though it seems to be difficult with btrfs *right now*, but that's a bug, not a feature)
<@adamwill:fedora.im>
21:11:59
no, that is not right (edit: this was a reply to conan's assertion)
<@zbyszek:fedora.im>
21:12:18
Yeah, but btrfs is our default fs, and widely popular. So if it doesn't work on btrfs, that's a major regression.
<@jkonecny:fedora.im>
21:12:42
adamw: you are not able to shrink BTRFS on GTK UI, just plain partitions IIRC
<@adamwill:fedora.im>
21:12:46
i would place that in the bucket of "reasons why attempting to land this now causes schedule risk"
<@adamwill:fedora.im>
21:13:03
jkonecny: yeah, I think that's right.
<@conan_kudo:matrix.org>
21:13:18
I never got around to figuring out why we have that restriction
<@conan_kudo:matrix.org>
21:13:24
since btrfs allows online shrink
<@adamwill:fedora.im>
21:13:29
it seems irrelevant, this is complicated enough already
<@cmurf:fedora.im>
21:13:57
ummm, ok so the next obvious proposal is keeping GTK UI for F40 and figuring out the answer to the thorny questions later (which I do not like, and am not yet advocating, I just want to explore the consequences of that)
<@conan_kudo:matrix.org>
21:14:16
the GTK UI is still tested in F40 since it's part of the flow for Fedora KDE
<@conan_kudo:matrix.org>
21:14:47
the main consequence is untangling the changes to the live session that was done for Workstation
<@adamwill:fedora.im>
21:14:50
gtkui is used for everything except workstation live.
<@cmurf:fedora.im>
21:14:50
like it seems to me we're a bit stuck how far we can go with webui without committing to both instant-apply and cockpit ui late landing
<@conan_kudo:matrix.org>
21:14:54
some of those involve non-upstream patches
<@jkonecny:fedora.im>
21:15:09
zbyszek: that is unfortune outcome of diversion of default partitioning between RHEL and Fedora - hard to find resources for BTRFS development in general
<@zbyszek:fedora.im>
21:15:44
RH being stubborn ;(
<@jkonecny:fedora.im>
21:16:10
not saying it's not true
<@jkonecny:fedora.im>
21:16:15
but still it's the outcome
<@jkonecny:fedora.im>
21:17:24
anyway - I wonder what would be the expectation from deferring this to F41? Do you expect that installer team will come with a new partitioning tool?
<@jkonecny:fedora.im>
21:17:40
or on F41 there will be just enough time?
<@jkonecny:fedora.im>
21:17:44
or what is expected here
<@adamwill:fedora.im>
21:17:49
so i think fesco should first decide if it actually wants to stand in the way of webui+cockpit *in principle*. do you want to try and say that an installer without feature X, Y or Z is unacceptable for fedora and will not be accepted?
<@adamwill:fedora.im>
21:18:09
(after thinking through the consequences of that)
<@cmurf:fedora.im>
21:18:13
yep, difficult question but needs an answer
<@jkonecny:fedora.im>
21:18:16
I'm asking mainly because of the blocker bug which is honestly still absurd to me (yeah I know adamw you already explained it to me 😄 )
<@adamwill:fedora.im>
21:18:23
after that, we could consider the question of whether landing it *right now for f40* is the right thing to do
<@conan_kudo:matrix.org>
21:18:59
I personally don't like a Web UI for a desktop application, but that ship sailed for a lot of things already :(
<@jkonecny:fedora.im>
21:19:15
if FESCO will reject Cockpit + installer than we probably have an issue pretty hard to be resolved - also you are killing a lot of work from the Cockpit team -- just FYI
<@conan_kudo:matrix.org>
21:19:20
I don't have a problem with Cockpit itself in principle, but I do have a problem with them asserting their partitioning model is okay
<@sgallagh:fedora.im>
21:19:53
Something I've been thinking about that I haven't had time to propose was this: What if we planned for a 12-month cycle once every three years for the release that follows the fork for CentOS Stream/RHEL. It would allow us to have a scheduled cycle for landing stuff we know will take more bake time than most releases. And I think "right after the fork for RHEL" seems like a good time...
<@dcantrell:fedora.im>
21:20:40
Put another way what userbase is waiting for this functionality and do they care about destructive turn based storage setup
<@cmurf:fedora.im>
21:20:46
i'm not sure what it would take for me to get on board with instant-apply partitioning: the user must wet ink sign a release form and scan it in?
<@conan_kudo:matrix.org>
21:20:59
or... we could just make changes that require more time to bake to be pushed to future releases
<@conan_kudo:matrix.org>
21:21:23
what makes lengthening the release cycle for everyone more attractive than just pushing out changes to future releases?
<@sgallagh:fedora.im>
21:21:59
Conan Kudo: Eh, I have answers but this discussion is already complicated. Let's revisit this later
<@zbyszek:fedora.im>
21:22:10
Yeah, I don't think we need 12-months cycles. Futures are developed asynchronously anyway.
<@jkonecny:fedora.im>
21:22:45
still can't help myself that Immediate action is a personal preference
<@conan_kudo:matrix.org>
21:22:58
me personally, I don't feel good about this
<@jkonecny:fedora.im>
21:23:05
exactly
<@sgallagh:fedora.im>
21:23:11
jkonecny: So is pulling the trigger on a shotgun, but we still put safeties on them...
<@cmurf:fedora.im>
21:24:25
following that metaphor is there some simple additional developer option, like a safety switch, that can get us on board with instant-apply?
<@zbyszek:fedora.im>
21:25:05
cmurf: I think this is a good analogy. Shotguns are just bad, and safeties and other duck tape appendages don't help enough.
<@cmurf:fedora.im>
21:25:20
like what else can be done with the UI or the messaging to convey the non-reversibility aspect of all the choices past that threshold?
<@conan_kudo:matrix.org>
21:25:48
I would like to put forth another question: why _must_ it work this way?
<@conan_kudo:matrix.org>
21:26:19
the UI and the backend udisks are already separate components, presenting things and holding back actions until we actually _do_ something is a well-known pattern
<@conan_kudo:matrix.org>
21:27:00
this is even more true with web UIs, which operate client side while the actual actions happen elsewhere "server side"
<@adamwill:fedora.im>
21:27:16
Conan Kudo: i don't think it's "it must be this way" so much as "who is going to pay to rewrite udisks2"?
<@jkonecny:fedora.im>
21:27:22
Conan Kudo: can't answer that - not an expert. However, it was said clearly from the team that this is not possible
<@conan_kudo:matrix.org>
21:27:36
I'm asking the question: why does it involve rewriting udisks
<@cmurf:fedora.im>
21:27:42
I don't know the development cost of the planned-layout-apply-later UIUX, like that whole logging aspect I look at is extremely detailed so there's a lot of code playing all those ordered (delayed) executions and tying them to tests and error pathways and also logging all of it
<@adamwill:fedora.im>
21:27:49
(and then, i guess, revise cockpit-storage around the change. and probably gnome-disks.)
<@sgallagh:fedora.im>
21:27:53
adamw: udisks2 doesn't have to be rewritten, but a modeling UI can happen atop it and udisks2 used to apply the changes when readty
<@conan_kudo:matrix.org>
21:27:54
we can just as easily just not send commands to udisks
<@zbyszek:fedora.im>
21:28:06
adamw: to answer your question: webui and cockpit are not the issue. But the huge regression in functionality is an issue. I think we're being put in front of a choice, either this or that, but maybe those are not the only possible answers. In particular, we had an essentially working installer in the past. After a few months of work, we have something that looks nice, but doesn't seem to cut it functionality-wise. So maybe we need to go back to what we had and try a different direction.
<@adamwill:fedora.im>
21:28:13
well, okay, but ultimately, who's gonna do that
<@sgallagh:fedora.im>
21:28:15
But I understand that we have limited resources.
<@jkonecny:fedora.im>
21:28:42
creating a storage planning is super hard to achieve, you need to model what will happen without it actually happened
<@sgallagh:fedora.im>
21:28:46
I'm also aware that the Anaconda team is scrambling with internal pressures around the (in my opinion, premature) dropping of X11
<@zbyszek:fedora.im>
21:28:58
BTW, I just tried "mount point assignment" in a VM, and it destroyed my existing data. :(
<@conan_kudo:matrix.org>
21:30:01
at this point, I don't know what we should do
<@conan_kudo:matrix.org>
21:30:07
we seem to be pushed into bad choices all around
<@jkonecny:fedora.im>
21:30:12
Stephen Gallagher: that is just one of the things we are dealing with ... ☹️
<@conan_kudo:matrix.org>
21:30:33
and I really don't feel good about any of our choices that we're being told to consider
<@adamwill:fedora.im>
21:31:13
so, let me play devil's advocate
<@adamwill:fedora.im>
21:31:26
if fesco were to frankly duck the Big Question and instead say "this is just too late, it's deferred to F41 because it's late"
<@cmurf:fedora.im>
21:31:40
i think proscribing instant-apply has its own consequences which is a bunch of developers working on this might write off the whole enchilada - like this is not the time for product development, unless folks really have developers lined up waiting to work on this
<@cmurf:fedora.im>
21:31:43
just the reality
<@adamwill:fedora.im>
21:31:44
and hope that Stuff Happens over the next fourish months to make the answer to the Big Question clearer
<@adamwill:fedora.im>
21:31:47
how mad would everyone be
<@conan_kudo:matrix.org>
21:32:07
I would be fine with it
<@conan_kudo:matrix.org>
21:32:18
at least then we can have a lower-pressure conversation with the Cockpit and Anaconda folks
<@adamwill:fedora.im>
21:32:27
(i am not pushing this outcome, just floating it as a possibility)
<@conan_kudo:matrix.org>
21:32:33
I feel like we're being boxed into bad choices now because there's Some Need(tm) for it in F40
<@jkonecny:fedora.im>
21:35:29
adamw: I won't be mad (maybe a while after the decison) but I would need to consider next steps where any of those are great
where I'm forced to do that without still getting feedback to almost anything
<@sgallagh:fedora.im>
21:36:03
jkonecny: If we reject this, what would it take to revert to the same installer as the other deliverables?
<@jkonecny:fedora.im>
21:36:16
and sorry but Fedora QE nor FESCO is target group of standard Fedora user
<@sgallagh:fedora.im>
21:36:18
Would it not simplify the maintenance on your team?
<@conan_kudo:matrix.org>
21:36:40
I'm sorry you're not getting feedback, what do we need to do to get more feedback for you.
<@conan_kudo:matrix.org>
21:36:58
This, however, is wrong. We're all Fedora users of varying levels of complexity.
<@jkonecny:fedora.im>
21:37:10
If you reject it than most probably Workstation SIG will reject web UI so we are again without release of web UI
<@sgallagh:fedora.im>
21:37:27
jkonecny: FESCo members aren't, no. But FESCo IS responsible for representing our target users. Which (unless it has changed) is meant to be developers, no?
<@adamwill:fedora.im>
21:37:31
oh, yeah, i was kinda assuming the choice would be 'defer the whole webui feature'
<@jkonecny:fedora.im>
21:37:39
get it release 😄 😄
<@jkonecny:fedora.im>
21:37:47
get it released 😄 😄
<@sgallagh:fedora.im>
21:37:49
(Specifically for Workstation)
<@conan_kudo:matrix.org>
21:38:22
creatives, developers, technical users, etc.
<@conan_kudo:matrix.org>
21:38:59
we are broader than developers, but developers may be one of the largest targets we have
<@jkonecny:fedora.im>
21:39:01
so basically this is partially issue raised by postponing the web UI on Fedora 39 because - we still implementing blidly
<@jkonecny:fedora.im>
21:39:36
so instead of half a year blind implementation it would be a year of blind implementation without feedback
<@conan_kudo:matrix.org>
21:39:47
fwiw, I would like for us to have some kind of deliverable with the webui installer even if it's nonblocking if that would help make it "less blind"
<@jkonecny:fedora.im>
21:40:04
plus you are rejecting our only feasible option for partitioning tool which is even more interesting issue to resolve
<@decathorpe:fedora.im>
21:40:13
bystander question: does "we need features X, Y, Z and instant-apply is not what we want" not count as feedback?
<@dcantrell:fedora.im>
21:40:31
Yeah why can't there be a "try it out" build with the web UI alongside the one everyone knows. Get feedback that eay
<@zbyszek:fedora.im>
21:40:48
Counter-proposal to a deliverable: We organize a test-day and for this purpose, we use a test ISO. It doesn't have to an official build.
<@conan_kudo:matrix.org>
21:40:50
and we should actively promote it as a preview build
<@adamwill:fedora.im>
21:40:53
we do have the osbuild image we could keep webui on
<@dcantrell:fedora.im>
21:40:58
I think it does
<@adamwill:fedora.im>
21:41:02
but i think the g-i-s integration maybe makes it harder
<@conan_kudo:matrix.org>
21:41:06
the Ubuntu folks did this with their installer work
<@jkonecny:fedora.im>
21:41:10
Fabio Valentini: as I said, I think this is personal preference issue and FESCO are people who re involved in Linux and Fedora for years
<@decathorpe:fedora.im>
21:41:11
wasn't this planned to happen half a year ago?
<@adamwill:fedora.im>
21:41:12
i'm not sure we can easily ship one image without the g-i-s customizations and one with
<@conan_kudo:matrix.org>
21:41:19
and openSUSE is doing it now with Agama too
<@conan_kudo:matrix.org>
21:41:38
I think it's absolutely worth it for us to introduce an artifact that always has it so people can try it and we can get more feedback
<@decathorpe:fedora.im>
21:41:40
personal preferences are feedback too. you should not discard that just because you don't like it ;)
<@adamwill:fedora.im>
21:41:41
Fabio Valentini: there were a few of these built, but i'm not sure how many people actually tried them.
<@cmurf:fedora.im>
21:41:56
Exactly why change proposals need to have all of such details relevant to the change in them. I didn't know about the cockpit UI addition until today.
<@jkonecny:fedora.im>
21:42:08
dcantrell: I wanted to do that on Fedora 39 but it was rejected that having two deliverables is hard to test -- I totally agree with that
<@cmurf:fedora.im>
21:42:13
A huge part of the change proposal is to avoid parties getting burned.
<@jkonecny:fedora.im>
21:42:48
as I'm still repeating Cockpit Storage is not forcing you to use it
<@adamwill:fedora.im>
21:42:52
jkonecny: if one of the deliverables is not release blocking, testing isn't an issue at all. it only becomes an issue of how difficult it is on development/releng side.
<@dcantrell:fedora.im>
21:42:58
It sounds like you have earned the right to say "I told you so"
<@sgallagh:fedora.im>
21:43:29
Maybe we don't ship an installer for F40 at all! Only upgrades are supported! (I'm getting tired)
<@dcantrell:fedora.im>
21:43:44
Yes we need to wrap this up
<@sgallagh:fedora.im>
21:44:30
Can we at least vote on one simple question? "Is the current situation something we are willing to ship to end-users?"
<@jkonecny:fedora.im>
21:44:32
Stephen Gallagher: that is in correlation with presentation about OpenSuse installer, the best installer for users is the one who doesn't exists. I so much agree with that!
<@jkonecny:fedora.im>
21:44:48
Stephen Gallagher: that is in correlation with presentation about OpenSuse installer, the best installer for users is the one which doesn't exists. I so much agree with that!
<@sgallagh:fedora.im>
21:44:49
If the answer is "no", let's approve the blocker and work towards figuring out how to unblock it over the next week.
<@adamwill:fedora.im>
21:44:50
there is no good partitioning UI.
<@adamwill:fedora.im>
21:45:24
Stephen Gallagher: i don't know that this makes much sense. the blocker is on the lack of a plan-then-apply mechanism. there is zero realistic prospect one of those is going to show up for beta.
<@cmurf:fedora.im>
21:45:41
I'm willing to ship it with caveats even though I reallllly don't like it. In my opinion the limit is asking for a safety switch, not a redesign.
<@adamwill:fedora.im>
21:45:56
we are not going to solve that problem in a week. we are either shipping f40 without plan-then-apply or we are shipping it without cockpit-storage.
<@adamwill:fedora.im>
21:46:07
(for workstation live, obviously)
<@sgallagh:fedora.im>
21:46:13
adamw: Yes, but the clearing of that blocker could be "only ship guided installation" or "revert to the old approach"
<@sgallagh:fedora.im>
21:46:23
Or some other option we haven't figured out because we're all tired.
<@zbyszek:fedora.im>
21:46:33
I think we should postpone this change for F41.
<@adamwill:fedora.im>
21:46:33
well, okay, if you want to try that, i guess.
<@jkonecny:fedora.im>
21:46:55
we can't ship web UI without Workstation SIG approval
<@zbyszek:fedora.im>
21:47:20
Stephen Gallagher: sorry, I'm tired too, but how does "guided installation" corresponds to one of the three choices in the installer right now?
<@sgallagh:fedora.im>
21:47:41
zbyszek: It's basically those three choices, but the "Modify storage" button above is removed.
<@adamwill:fedora.im>
21:48:05
this would effectively only allow installs to systems with sufficient free space, or by wiping entire disks.
<@sgallagh:fedora.im>
21:48:12
Yes
<@adamwill:fedora.im>
21:48:15
okay.
<@zbyszek:fedora.im>
21:48:34
Hmm, that's confusing. So I don't think this is really "guided". I tried it, and "mount point assignment" is very bare-bones.
<@adamwill:fedora.im>
21:48:58
yes, to be clear, it is not at all (yet) a guided mode as envisaged in the Change, with the advanced capabilities implied ther.
<@jkonecny:fedora.im>
21:49:22
we would like to add options based on feedback --- ups ...
<@dcantrell:fedora.im>
21:49:46
How about for partition resizing we show Tetris and each block is a logical block on the volume and...well, you know
<@jkonecny:fedora.im>
21:49:48
we would like to add options based on feedback --- ups no feedback yet...
sorry it's late and I had hard day
<@sgallagh:fedora.im>
21:50:35
jkonecny: I know, and I really do sympathize. You're in a tough position here no matter how this discussion goes. It's not unnoticed and I don't think anyone here is happy about it.
<@sgallagh:fedora.im>
21:51:45
We know you're doing your best with minimal resources.
<@sgallagh:fedora.im>
21:52:48
jkonecny: If we said "defer the new UI to F41 and we'll schedule three Test Days in the next three months", would that be acceptable?
<@conan_kudo:matrix.org>
21:53:01
yes, jkonecny I do appreciate everything you and your team are doing
<@sgallagh:fedora.im>
21:53:38
jkonecny: If we said "defer the new UI to F41 and we'll schedule three Test Days in the next five months", would that be acceptable?
<@adamwill:fedora.im>
21:54:11
i'm also honestly wondering if we might try using server as a testbed instead of workstation, especially if it's going to be a non-blocking image. that avoids a lot of the complexity of the g-i-s integration stuff. and maybe btrfs to a degree (since server defaults to xfs).
<@sgallagh:fedora.im>
21:54:36
adamw: That's a clever idea
<@conan_kudo:matrix.org>
21:54:53
I think a live and an install image are both valid cases
<@adamwill:fedora.im>
21:55:04
and after all, if we're considering our Significant Downstream here (ahem), they don't ship a GNOME live install image, AFAIK.
<@sgallagh:fedora.im>
21:55:11
Conan Kudo: Absolutely, but maybe start with the "easier" one?
<@jkonecny:fedora.im>
21:55:43
adamw: we can't adopt Server, we didn't focused on the required feature work there
<@jkonecny:fedora.im>
21:55:53
our focus was solely on this deployment
<@cmurf:fedora.im>
21:56:18
my vague recollection is Server folks required some of the RAID stuff to be wired up in the custom partitioning?
<@conan_kudo:matrix.org>
21:56:46
and other spins can't use it because there is no equivalent to g-i-s for them
<@adamwill:fedora.im>
21:56:54
jkonecny: ah, okay.
<@sgallagh:fedora.im>
21:57:49
But still: would a delay to F41 be okay as long as we preemptively schedule multiple Test Days (and announce them widely)?
<@sgallagh:fedora.im>
21:58:03
That should help get the real feedback you neeed
<@jkonecny:fedora.im>
21:58:06
Conan Kudo: GIS shouldn't be the requirement
<@sgallagh:fedora.im>
21:58:07
That should help get the real feedback you need
<@conan_kudo:matrix.org>
21:58:25
without g-i-s we have no way to set locale with the new installer
<@conan_kudo:matrix.org>
21:58:32
those features were not reimplement, last I checked
<@conan_kudo:matrix.org>
21:58:36
*reimplemented
<@sgallagh:fedora.im>
21:58:41
Conan Kudo: Let's avoid the minutiae for this decision, please?
<@jkonecny:fedora.im>
21:59:13
We have welcome screen with language selection, however, missing keyboard configuration which implemented for Gnome only so far
<@zbyszek:fedora.im>
22:00:26
OK, let's do a vote.
Proposal: Changes/AnacondaWebUIforFedoraWorkstation is postponed to F41.
<@sgallagh:fedora.im>
22:01:15
Addendum: FESCo and QA will help arrange mass-testing early in the F41 cycle
<@zbyszek:fedora.im>
22:01:38
Ack, +1 with the addendum, FTR.
<@conan_kudo:matrix.org>
22:01:47
Addendum: mass-testing should be scheduled shortly after F40 GA
<@jkonecny:fedora.im>
22:01:51
if you still keep around the bug with Instant apply as blocker you might not need to do testing for F41
<@sgallagh:fedora.im>
22:01:52
+1 including addendum
<@jkonecny:fedora.im>
22:01:57
we won't be able to deliver it
<@jkonecny:fedora.im>
22:02:03
most probably
<@sgallagh:fedora.im>
22:02:59
jkonecny: Understood, but we'll have time to figure out what is an acceptable compromise.
<@jkonecny:fedora.im>
22:03:45
* don't know what to say or expect here 😄
<@zbyszek:fedora.im>
22:03:55
jkonecny: I don't think this is a blocker for testing. In fact, it might be good to test with the current model, incl. insta-apply. Maybe users will be happy, and then we (FESCo) will reconsider our stance. Or maybe users will not be happy, and then you (the webui developers) will have to reconsider.
<@adamwill:fedora.im>
22:04:52
if this change is deferred i'll remove blocker status from the bug, as it really doesn't make sense to track it as a 'blocker' for months at a time
<@jkonecny:fedora.im>
22:05:04
zbyszek: what do you think by that? How to test it, what would be the deliverable?
<@adamwill:fedora.im>
22:05:19
if that is going to happen I would expect *somebody* to take charge of answering the question "if not this, then what?" because it doesn't feel like my job
<@sgallagh:fedora.im>
22:05:31
adamw: I'll own that
<@zbyszek:fedora.im>
22:05:55
I would ask users to install the image on spare laptops, or try to upgrade a VM they have, etc. Just normal installation tasks.
<@cmurf:fedora.im>
22:06:06
well an early step would be to refresh the change proposal to reflect the actual reality of the product
<@dcantrell:fedora.im>
22:06:16
Is everyone chatting in back channels?
<@dcantrell:fedora.im>
22:06:16
+1
<@jkonecny:fedora.im>
22:06:29
zbyszek: still not sure what would be the deliverable?
<@sgallagh:fedora.im>
22:07:04
We are over two and a half hours on this meeting. FESCo members, please vote on zbyszek 's proposal
<@zbyszek:fedora.im>
22:07:22
We're at +3, 0, 0.
<@dcantrell:fedora.im>
22:07:36
I did but I don't know if it went thru. +1
<@dcantrell:fedora.im>
22:07:45
I had to go to 4G
<@zbyszek:fedora.im>
22:08:02
Yes, it did already.
<@dcantrell:fedora.im>
22:08:18
Ok, cool
<@conan_kudo:matrix.org>
22:08:19
+1 with addendums
<@zbyszek:fedora.im>
22:08:32
Conan Kudo: I understand that your addendum is the same as Stephen Gallagher 's?
<@conan_kudo:matrix.org>
22:08:38
it is not
<@conan_kudo:matrix.org>
22:08:41
I added a timing condition
<@conan_kudo:matrix.org>
22:08:58
I'm essentially saying that we need to do it right away vs just early
<@conan_kudo:matrix.org>
22:09:25
the F41 dev cycle starts in August, I want us to start in May
<@sgallagh:fedora.im>
22:09:46
I left it vague in the interest of letting the installer folks tell us when, but I don't feel strongly
<@sgallagh:fedora.im>
22:10:10
Conan Kudo: The F41 dev cycle started at the fork...
<@zbyszek:fedora.im>
22:10:15
I guess it doesn't matter. "Shortly after F40 GA" and "Early in the F41 cycle" are the same.
<@jkonecny:fedora.im>
22:10:19
hard to say but my expectation would be no for F41... but I need to revisit the workbench to find out
<@sgallagh:fedora.im>
22:10:41
jkonecny: "no" to what?
<@jkonecny:fedora.im>
22:10:46
web UI
<@jkonecny:fedora.im>
22:10:49
given to conditions
<@jkonecny:fedora.im>
22:11:00
and RHEL work we are expected to get
<@sgallagh:fedora.im>
22:11:07
jkonecny: We're not putting conditions on it until we get the initial round of user feedback
<@sgallagh:fedora.im>
22:11:17
That's what I'm trying to say with the mandatory early test days
<@conan_kudo:matrix.org>
22:11:46
right, we're not even forcing the cockpit folks to change the storage interaction model in this proposal
<@zbyszek:fedora.im>
22:11:54
OK, do we have another FESCo member to finish the vote? Or are we below qorum?
<@zbyszek:fedora.im>
22:11:58
OK, do we have another FESCo member to finish the vote? Or are we below quorum?
<@conan_kudo:matrix.org>
22:12:48
I think we're below quorum with jednorozec gone
<@dcantrell:fedora.im>
22:13:11
Come on
<@humaton:fedora.im>
22:13:13
I am here
<@dcantrell:fedora.im>
22:13:18
This meeting needs to end
<@humaton:fedora.im>
22:13:30
give me minute I will get bak at computer
<@jkonecny:fedora.im>
22:14:30
I'm going off - no need for me. I need some time to get energy for tomorrow work what is expecting me
<@zbyszek:fedora.im>
22:14:58
jkonecny: thank you for being here.
<@sgallagh:fedora.im>
22:15:05
jkonecny: Thank you for coming. We really do appreciate all you do
<@humaton:fedora.im>
22:16:02
Ok with the addenum going for f41, +1
<@zbyszek:fedora.im>
22:16:13
Phew.
<@zbyszek:fedora.im>
22:16:52
!agreed Changes/AnacondaWebUIforFedoraWorkstation is postponed to F41. FESCo and QA will help arrange mass-testing early in the F41 cycle, shortly after F40 GA. (+5, 0, 0)
<@zbyszek:fedora.im>
22:17:36
!topic Next week's chair
<@zbyszek:fedora.im>
22:17:50
Vlntrs?
<@zbyszek:fedora.im>
22:18:18
One...
<@zbyszek:fedora.im>
22:18:24
Two...
<@zbyszek:fedora.im>
22:18:29
Three...
<@zbyszek:fedora.im>
22:18:37
OK, I'll do it. I'll try not to be late.
<@zbyszek:fedora.im>
22:18:39
!action zbyszek will chair next meeting
<@zbyszek:fedora.im>
22:18:48
!topic Open Floor
<@zbyszek:fedora.im>
22:18:56
I hope we can skip this.
<@zbyszek:fedora.im>
22:19:03
I'll close in 30 s.
<@sgallagh:fedora.im>
22:19:12
OK, I'm going back to my PTO
<@zbyszek:fedora.im>
22:19:27
Stephen Gallagher: thanks for coming.
<@zbyszek:fedora.im>
22:19:33
!endmeeting