I'm +1, unless someone can give a good reason why it's still needed. We saved a lot of compose time when we removed the Cloud Variant repos/buildinstalls.

I do not know the exact reason(s), but I suspect there were some.

Perhaps @lsedlar could chime in here from a pungi viewpoint

-1 to the change, the Cloud tree was there because of the now defunct cloud edition that was ever fully realised. the necessary anaconda changes were never made. in order to make the edition useful with the new way of dealling with product specific defaults it needed work to make anaconda work. the workstation install tree offers a way for people to do a traditional install using either a boot.iso or pxe boot and get the workstation default install options.

in order to remove the workstation install tree anaconda will need changes, if that happens then the change can be made.

the decision for such a change would have to come from the workstation working group

boot and get the workstation default install options.

Do you know where those default install options live today? I know we had the fedora-productimg-workstation but that doesn't exist any longer because all of that content got merged into anaconda.

From pungi config point of view disabling the repo and install tree is easy, but there is currently no option to disable just the repo and keep running lorax (no dependencies between the two, it's just not implemented). There are currently three deliverables in Rawhide that consume packages or install tree from the Workstation repo. They might work with Everything instead, I don't really know.

I'm not so sure how significant the reduction in compose time would be. Looking at Fedora-Rawhide-20180321.n.0, it took 7m18s to determine what packages should be in the repo, 30s to hardlink them into the compose/ subdir and 3m43s to run all the createrepo commands.

Running lorax for Workstation took about 10 minutes (for x86_64), but it runs in parallel to doing the same work for Everything which took about 20 minutes, so there would almost no effect to total compose running time. It would reduce load on Koji though.

From pungi config point of view disabling the repo and install tree is easy, but there is currently no option to disable just the repo and keep running lorax

I think the idea was that we possibly don't need either

I'm not so sure how significant the reduction in compose time would be.

That's fair, but biggest slow down for Cloud (I think) was the fact that it was running on s390x (and the slow network link in between). Also if we don't build the repo and buildinstall then we don't need to run all the things (including repoclosure) for all the different architectures for Workstation.

The one thing we can do to "test" to see if the workstation deliverables are still good even if the Workstation repo/buildinstall goes away is to create some koji tasks and just point them at the Everything buildinstall/repo like here: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180321.n.0/compose/Everything/

@dustymabe yes it moved into anaconda, the only way that the code path is followed now is via the variant field of the .buildstamp file inside of the anaconda runtime. so you have to have a build of the anaconda runtime to get the workstation options

https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/product.py

there is a check in https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/installclasses/fedora_workstation.py for the productVariant being workstation

but again the decision is not release engineering's, it is the decision of the workstation working group

@ausil. Thanks for those pointers! That helps.

but again the decision is not release engineering's, it is the decision of the workstation working group

I agree with that. If we prove the artifacts are equivalent with no Workstation repo/buildinstall then I can try to get workgroup approval. If it's not possible then it's not worth asking them I don't think.

it is not possible to get an installer that defaults to workstation without making a workstation installer and install tree.

it is not possible to get an installer that defaults to workstation without making a workstation installer and install tree.

Anaconda supports an installclass arg in the kickstart. For the kickstarts that we use the Workstation buildinstall for then we should just be able to add installclass --name="Fedora Workstation" to them.

For the netinstall I don't see why we couldn't add an inst.installclass as a kernel command line kickstart option and make a second entry in syslinux that is selectable by the user to say they want Workstation defaults.

The Fedora Workstation install class has been merged into the Anaconda source code and the Fedora Workstation product image should be (AFAIK) decommissioned.

Install class selection now works by Anaconda reading the .buildstamp field and checking checking for the Variant key.

If there is Variant=Workstation, the Fedora Workstation install class will be used. If there is Variant=Server then Fedora Server install class will be used, etc.

The different contents of the .buildstamp file could be actually the only difference between the individual installation images if I understand things correctly.

The Fedora Workstation install class has been merged into the Anaconda source code and the Fedora Workstation product image should be (AFAIK) decommissioned.
Install class selection now works by Anaconda reading the .buildstamp field and checking checking for the Variant key.
If there is Variant=Workstation, the Fedora Workstation install class will be used. If there is Variant=Server then Fedora Server install class will be used, etc.
The different contents of the .buildstamp file could be actually the only difference between the individual installation images if I understand things correctly.

this is a different problem, the productimg have gone away already

it is not possible to get an installer that defaults to workstation without making a workstation installer and install tree.

Anaconda supports an installclass arg in the kickstart. For the kickstarts that we use the Workstation buildinstall for then we should just be able to add installclass --name="Fedora Workstation" to them.

That just sets install class for the given installation run - it won't make the result into a Fedora Workstation installation image. That is governed by buildstamp and there is no reason why install class used during an Anaconda installation run should influence that (eq. as I understand things buildstamp is something the thing that runs anaconda to generate the image writes out).

For the netinstall I don't see why we couldn't add an inst.installclass as a kernel command line kickstart option and make a second entry in syslinux that is selectable by the user to say they want Workstation defaults.

I don't see the difference from just making sure Variant in the .buildstamp file on the image point to correct installclass. Setting default boot options means changing the (syslinux?) bootloader config, which is yet again a text file located on the image.

Well, actually there is a small difference - the image bootloader config likely comes from a package vs something the "image generator" that runs Anaconda writes.

On the other hand you still need to tell the image-generator:

"This thing will be a Workstation image!"

So you might as well tell it to put the right string to the Variant field in .buildstamp.

That just sets install class for the given installation run - it won't make the result into a Fedora Workstation installation image.

right. I'm just saying that we can use the Everything buildinstall along with installclass --name="Fedora Workstation" to do our anaconda runs where we create image artifiacts. For example one of them is the workstation image build. We can just point 'install_tree_from': 'Everything' and 'repo': 'Everything' and then update the fedora-disk-workstation.ks to have installclass --name="Fedora Workstation".

I don't see the difference from just making sure Variant in the .buildstamp file on the image point to correct installclass. Setting default boot options means changing the (syslinux?) bootloader config, which is yet again a text file located on the image.

The difference is we wouldn't have to create two separate deliverables (one Workstation netinstall and one Everything netinstall). The user chooses at runtime using the syslinux menu. That's not a switch you can do with the buildstamp file IIUC.

The difference is we wouldn't have to create two separate deliverables (one Workstation netinstall and one Everything netinstall). The user chooses at runtime using the syslinux menu. That's not a switch you can do with the buildstamp file IIUC.

Oh, so that's the aim - an actual single image with user selecting the install class via menu. Yeah, that's something that should work & could be handy.

But not sure if there are some broken usecases and possibly branding issues if the actual variant specific netinst images were deprecated as well.

Oh, so that's the aim - an actual single image with user selecting the install class via menu. Yeah, that's something that should work & could be handy.

Cool. The only existing gap I see is supporting something like 'inst.installclass="Fedora Workstation" on the kernel command line. is that a reasonable RFE to open?

Cool. The only existing gap I see is supporting something like 'inst.installclass="Fedora Workstation" on the kernel command line. is that a reasonable RFE to open?

Yeah - we basically don't support that yet because no one asked for it till now.

Filed https://pagure.io/fedora-workstation/issue/45

This applies to Server, too, right?

This applies to Server, too, right?

I don't think so because we do embed a yum repo onto the ISO for the server DVD ISO. So we need a seperate directory with rpms and yum repo metadata for that, right?

@dustymabe Oh, yeah, right. So we'd have to drop the DVD ISO first as a prereq for that. :)

https://github.com/rhinstaller/anaconda/pull/1716 -- there is now inst.product and inst.variant support in kickstart. Where does that get us as far as removing the separate tree?

Workstation WG is okay with no boot.iso. So, we will removing workstation install tree.

https://pagure.io/fedora-workstation/issue/45

From Fedora RelEng meeting on Mar 27 2019:

#info mboddu will file a change request for removing workstation install tree for F31. Once approved, he will make the necessary changes like pungi config, openqa, deliverables wiki page...

Didn't Silverblue build from the Workstation repo tree at least at some point? I recall us having issues more than once because a package Silverblue needed to include was not in the Workstation tree. Has that changed?

Didn't Silverblue build from the Workstation repo tree at least at some point? I recall us having issues more than once because a package Silverblue needed to include was not in the Workstation tree. Has that changed?

I'm working from memory here so excuse mistakes. Yes SB used to pull from the workstation repo (to gain parity with Fedora Workstation comps), but it didn't need to. I think at some point the OSTree phase of pungi was switched to use the global repo (so it could start OSTree phases earlier). Either way pulling from the non-workstation repo should be fine and preferable IMHO and i think it's what is already being done.

Just had reason to come across this yesterday. indeed we changed Silverblue to build from the Everything tree, in 86a78b87cad705a1069faa5c74036a72aeb03d9e . But the ARM Workstation disk images are still built from the Workstation tree:

'^Workstation$': [
    {
        'image-build': {
                'format': [('raw-xz','raw.xz')],
                'name': 'Fedora-Workstation',
                'kickstart': 'fedora-disk-workstation.ks',
                'distro': 'Fedora-22',
                'disk_size': 11,
                'arches': ['armhfp', 'aarch64'],
                'repo': 'Workstation',
                'install_tree_from': 'Workstation',
                'subvariant': 'Workstation',
                'failable': ['*'],
                 }
    },

That's from current pungi-fedora master fedora.conf. So that at least would need changing.

This was changed in 39683dd517c4ca3a9bfadc42805ae813602d4363 to use the Everything repo.

Is there anything left before we turn it off?

Updates to kickstarts to consume everything and not the workstation repo?

@kevin
Is there anything left before we turn it off?

I think we need to actually turn off creating the workstation repo now so we can actually speed up the compose (removing things that need to be done will reduce the compose time, right?). Here is a stab at trying to do that: https://pagure.io/pungi-fedora/pull-request/743#

@pbrobinson
Updates to kickstarts to consume everything and not the workstation repo?

I don't think this is necessary. I believe koji injects the specified repo into the kickstarts for you. For example:

repo --name="koji-override-0" --baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n.0/compose/Everything/x86_64/os
# Use network installation
url --url="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n.0/compose/Everything/x86_64/os"

@pbrobinson
Updates to kickstarts to consume everything and not the workstation repo?

I don't think this is necessary. I believe koji injects the specified repo into the kickstarts for you. For example:
repo --name="koji-override-0" --baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n.0/compose/Everything/x86_64/os

Use network installation

url --url="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n.0/compose/Everything/x86_64/os"

Sounds about right, it's been a while since I looked directly, was just making sure it was addressed one way or the other

BTW, I think there is a wrinkle here: it may make Workstation deliverables larger, due to how we deal with soft deps. IIRC, how the compose tools work is that if a soft dep is available in the compose repo it'll be pulled in; if not, it will be skipped.

So there will likely be cases where a package that was left out of a deliverable before (because it wasn't in the Workstation tree) will be in the deliverable now (because it'll definitely be in the Everything tree).

Not necessarily a big problem, just worth a note I figured.

@adamwill thanks for pointing that out. it will certainly help us to keep that info in the back of our minds if we encounter any obscure issues.

I think we can close this now. In Fedora-Rawhide-20190812.n.0 the compose FINISHED_INCOMPLETE without a Workstation yum repo.

Any other things we need to do? Any changes to clients? Any other changes to media?

Should we send an email to devel@ list to FYI everyone?

And it seems to have not blown up the size of the ISO noticeably, FWIW

In that case, I think we should disable installation of weak deps by default for images. Or find out what has pulled in so much stuff.

In that case, I think we should disable installation of weak deps by default for images. Or find out what has pulled in so much stuff.

But he said it "seems to have NOT blown up the size", right?

Oh, I'm just blind :) :broken_heart:

armv7 workstation still seems to be trying to use a Workstation repo:

https://koji.fedoraproject.org/koji/taskinfo?taskID=36992997

DEBUG util.py:585: BUILDSTDERR: Unable to create appliance : Failed to find group 'core' : no such group: @core

armv7 workstation still seems to be trying to use a Workstation repo:

proposed fix: https://pagure.io/pungi-fedora/pull-request/752

All done..

:goat: