FESCo has been asked to make a decision on what approach we want to take on netinstall images for Beta. There are several options with varying degrees of difficulty.
We need a decision on which of these approaches we want to deliver in Fedora 21 Beta immediately (I'd say by EOB Monday) so we can attempt to implement in time for the Beta RC and avoid a slip. Please vote immediately.
(If we don't get responses in time, I think we need to default to 1), simply because it's guaranteed to work.)
In the interest of not slipping, I'm leaning towards 1) right now, with 2) as my second choice. I think 3) is unnecessary, because in that situation, you might as well just be using the DVDs.
My vote:
prefer 1
2 if we can't do 1 or it ends up being easier.
I'd prefer not to do 3.
You left out option 4, which is to not do netinstall at all. I'm not necessarily advocating for that, but it's what we did for Alpha and it's an option here as well.
My preference:
2
1 with Server being the product
4
3
I'm for the (1) in Beta, to avoid slip.
However I'm for (2) in case of the final 21 release.
I think either we need to quickly find whether we are able to do (2) for Beta and the hacks are not too ugly or we should do (1) for both beta and final. Changing this in between beta and final is bad. I am very much against (3) and (4) given the option (1) seems doable without problems.
Also in case of (1) the selected product should be Server in my opinion.
I probably should have detailed the two potential hacks we came up with for 2) when I sent this out originally, but I was rushing out the door (then promptly had a busy weekend and didn't get a chance to follow up).
There are two ways we can address this
The product-specific repo approach: We ship a special repo file on the install image only that points to the product-specific tree for installation. This install tree makes one compose-time change to the comps.xml data: it arbitrarily changes the <display_order> tag for the product being composed to rank higher than any of the other possible environment groups. The <display_order> tag is treated as "cannot-merge" by the depsolvers and so the first-ordered one will win (we solve this by giving the product-specific repo a repo-id like [0-product] so that it will always be processed first). As a result, Anaconda will pick the Product environment as the default to display.
The anaconda override approach: We patch anaconda such that it will check if a particular file exists on the install media. If it does, the contents of that file will be the environment name that it should display by default (trumping the <display_order> tag in comps). If the file or its contents do not exist, it should fall back to the classic approach of checking the <display_order> tags.
Also, I am strongly opposed to having a different decision made on the install media approach between Beta and Final. It defies the intention of Beta (which is meant to be close to the final state of things, with only bugfixes going in). If we decide to go with 1) in Beta, I think that needs to remain the case for Final.
I'm for 2 and 1 in that order.
Can 2 be addressed with per-products updates.img files without otherwise patching anaconda? That serves both as the "particular file" and the implementation.
jwboyer: for the record, this:
"You left out option 4, which is to not do netinstall at all. I'm not necessarily advocating for that, but it's what we did for Alpha"
is not accurate. For Alpha we shipped netinst images that were nominally Product-y (they were labelled Server and Workstation and built out of / shipped in the Server and Workstation trees) but acted as universal images (they both offered all environments OOTB, and defaulted to Cloud Server since it comes first alphabetically among the equally-ranked environments).
So, it's monday night...
I see 4 votes giving option 1 highest priority
I see 2 votes giving option 2 highest priority
(I think, it's a bit hard to tally).
So, what shall we do here? We are very low on time to avoid a beta slip.
It seems like there are enough positive votes for either 1 or 2 to pass, so it sounds like collectively we recommend and approve 1 (but would also be okay with 2 if it doesn't cause a slip).
we need someone to do this really ASAP because comps changes do not take effect until the next mash, which is a multi-hour thing. i.e., to spin tomorrow, we need comps changes done today.
Replying to [comment:9 adamwill]:
jwboyer: for the record, this: "You left out option 4, which is to not do netinstall at all. I'm not necessarily advocating for that, but it's what we did for Alpha" is not accurate. For Alpha we shipped netinst images that were nominally Product-y (they were labelled Server and Workstation and built out of / shipped in the Server and Workstation trees) but acted as universal images (they both offered all environments OOTB, and defaulted to Cloud Server since it comes first alphabetically among the equally-ranked environments).
OK, fair. FESCo did decide it wasn't an Alpha blocker though, which means it's great we got something out but we would have shipped even if there was nothing working. I expressed concern about hitting more issues when we came around for Beta, so I'm glad to see there's been progress but perhaps not as much as we need.
In order to hit our Go on Thursday (necessary to release on Tuesday) I've pushed https://git.fedorahosted.org/cgit/comps.git/commit/?id=a17b291b89a2a636a518aa9408a8a09870fddd8f while we figure this out (which accomplishes 1) above).
Attempting to tally the votes with scores (3 for first choice, 2 for second, one for third and zero for last):
This brings us into a lovely tie between 1 and 2 (if this is a reasonable methodology)
We either need to have a tie-breaker or else do nothing and 1) will just land by default.
Note: at this point, it's pretty much a guarantee that 2) will cause a slip, barring a miracle. We need at least Tuesday to land either one of the fixes, then test a compose if we're lucky on Wednesday and have only the Wednesday night compose to fix any issues that arise before Go/No-Go on Thursday. Perhaps we should check in with the Accepted Blocker owners tomorrow morning and figure out if we're likely to slip anyway before we commit to implementing one of these hacks?
I think we should not slip just for this so unless we slip for anything else we should go with 1. But please please change the default to be Server and not Cloud.
If we remove Cloud, does that remove the need for any hacks?
The Cloud SIG wanted it there, but there are several good reasons that I don't think it should be, so I'm going to re-argue. Primarily, there are enough kickstart hacks that I think it's misleading -- you don't get a good starting point for making a cloud image by doing it that way. You're much better starting with the kickstart.
Replying to [comment:15 tmraz]:
That was the change I mentioned in comment 14.
Replying to [comment:17 mattdm]:
No, because to implement 2) we'd still need to have a decision path to handle Server vs. Workstation.
Right now, I've changed it so that Server always come up as the default (once we recompose with the latest comps), so that at this point if we do nothing, we have effectively implemented 1) with Server as the default.
If we end up with option 1, can we ship just a single netinstall image, as opposed to shipping two images, fedora-server-netinstall.iso and fedora-workstation-netinstall.iso that behave exactly the same for all practical purposes?
Replying to [comment:19 kalev]:
We can, but it amounts to deciding between two distasteful options:
Replying to [comment:20 sgallagh]:
Replying to [comment:19 kalev]: If we end up with option 1, can we ship just a single netinstall image, as opposed to shipping two images, fedora-server-netinstall.iso and fedora-workstation-netinstall.iso that behave exactly the same for all practical purposes? We can, but it amounts to deciding between two distasteful options: We arbitrarily pick the Fedora Server (or Workstation) netinstall and ship that one, with that Product's branding on Anaconda.
No need to choose between those two. We already have a generic netinstall image being produced nightly, as part of the daily compose. http://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/images/boot.iso
Replying to [comment:21 kalev]:
I wasn't aware of that. I just tried it out with last night's compose and it seems to work (also it confirms that my patch to comps did indeed switch the default to Server)
So I suppose that's an option, assuming that's truly a universal image and can be branded separately from the Products.
Note that it might take some releng work to use that image. It's created because we build the branched tree much like rawhide every night.
It's not created as part of a regular compose for a release. (That tree is not installable/made installable).
Not to say we couldn't use that image (we use the packages and repos), but might need releng to adjust scripts or the like to do so.
We discussed this at Workstation 2014-10-22 meeting today and the Workstation WG agreed that:
"Workstation is OK with netinstall defaulting to Server, but asks FESCo to only ship a single netinstall and remove the Workstation specific netinstall and install tree from F21."
Basically, if we ship a netinstall that's labelled as Workstation, we would want it to at least default to the correct package selection. If it doesn't do that, then it doesn't make sense to ship a Workstation labelled netinstall.
With this in mind, I am +1 to option 1 that sgallagh presented in the original proposal.
From the FESCo meeting:
See full log at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-22/fesco.2014-10-22-17.00.log.html#l-334
This was dropped for Beta RC1 (and will also be dropped in RC2)
Note, Beta shipped superficially with the behaviour we want, but it is still using product-specific repositories behind the scenes, and consequently mirrormanager is still having to point to them, which is a bunch of wasted work and unnecessary complication. It also causes issues with getting fedup working (life's too short to explain, just trust me and dgilmore, it does).
We should drop the product-specific repo stuff. See https://bugzilla.redhat.com/show_bug.cgi?id=1128474#c24 .
Also note that Beta still had a Cloud netinst image, which I'm guessing is an oversight, not intentional:
https://dl.fedoraproject.org/pub/fedora/linux/releases/test/21-Beta/Cloud/x86_64/iso/
if we don't want that, we should drop it for Final TC2+.
beta has a cloud netinst and it is intentional. It is needed to make the cloud images and docker base image. it is needed by any user wanting to reproduce out work in the same way, as such it will not be removed from final. for f22 we will look at options to put it into a different name space on the mirrors.
Login to comment on this ticket.