ngompa reported a new issue against the project: `releng` that you are following: `` Recently, we stopped producing [the Cloud repo tree](https://pagure.io/pungi-fedora/pull-request/577) as part of composes to speed things up and reduce the number of useless deliverables.
I suggest we also stop producing the Workstation repo tree for composes, as we don't use it or need it. Today, for the Workstation Edition, we produce two main artifacts: the live ISO and the branded netinstall ISO.
As far as I'm aware, the branded net install ISO differs from the main Fedora netinstall ISO only in branding and defaults through the anaconda productimg embedded within. It uses the `Everything` repo tree like the regular netinstall ISO, and is functionally similar to the regular netinstall ISO.
Since the Workstation netinstall doesn't need it, and we don't produce a Workstation install DVD ISO, I do not see a reason to keep producing the Workstation repo tree. Not producing the tree would help reduce the compose time significantly, too. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
kevin added a new comment to an issue you are following: `` I do not know the exact reason(s), but I suspect there were some.
Perhaps @lsedlar could chime in here from a pungi viewpoint
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` -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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` in order to remove the workstation install tree anaconda will need changes, if that happens then the change can be made. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` the decision for such a change would have to come from the workstation working group ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
lsedlar added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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... ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` @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/installclasse... for the productVariant being workstation
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` but again the decision is not release engineering's, it is the decision of the workstation working group ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: `` it is not possible to get an installer that defaults to workstation without making a workstation installer and install tree. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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]( http://anaconda-installer.readthedocs.io/en/latest/kickstart.html#installcla...) 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.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
m4rtink added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ausil added a new comment to an issue you are following: ``
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 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
m4rtink added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
m4rtink added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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](https://pagure.io/pungi-fedora/blob/586b7ec6721d596972a23f59074bb000024e569b...). 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
m4rtink added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
m4rtink added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
kevin added a new comment to an issue you are following: `` Filed https://pagure.io/fedora-workstation/issue/45 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
mattdm added a new comment to an issue you are following: `` This applies to Server, too, right? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
mattdm added a new comment to an issue you are following: `` @dustymabe Oh, yeah, right. So we'd have to drop the DVD ISO first as a prereq for that. :) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
pfrields added a new comment to an issue you are following: `` 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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
mohanboddu added a new comment to an issue you are following: `` 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... ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
adamwill added a new comment to an issue you are following: `` 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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
adamwill added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
kevin added a new comment to an issue you are following: `` This was changed in 39683dd517c4ca3a9bfadc42805ae813602d4363 to use the Everything repo.
Is there anything left before we turn it off?
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
pbrobinson added a new comment to an issue you are following: `` Updates to kickstarts to consume everything and not the workstation repo? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
@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](https://koji.fedoraproject.org/koji/taskinfo?taskID=36828294):
``` repo --name="koji-override-0" --baseurl=https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n... # Use network installation url --url="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n..." ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
pbrobinson added a new comment to an issue you are following: ``
@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... # Use network installation url --url="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190806.n..."
Sounds about right, it's been a while since I looked directly, was just making sure it was addressed one way or the other ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
adamwill added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: `` I think we can close this now. In [Fedora-Rawhide-20190812.n.0](https://pagure.io/dusty/failed-composes/issue/2254) the compose FINISHED_INCOMPLETE [without a Workstation yum repo](https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190812.n...).
Any other things we need to do? Any changes to clients? Any other changes to media? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: `` Should we send an email to devel@ list to FYI everyone? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
mattdm added a new comment to an issue you are following: `` And it seems to have not blown up the size of the ISO noticeably, FWIW ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ignatenkobrain added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
ignatenkobrain added a new comment to an issue you are following: `` Oh, I'm just blind :) :broken_heart: ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
kevin added a new comment to an issue you are following: `` 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
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
dustymabe added a new comment to an issue you are following: ``
armv7 workstation still seems to be trying to use a Workstation repo:
proposed fix: https://pagure.io/pungi-fedora/pull-request/752 ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
The status of the issue: `Consider no longer producing the Workstation repo tree in composes` of project: `releng` has been updated to: Closed as Fixed by kevin.
kevin added a new comment to an issue you are following: `` All done..
:goat: ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7403
rel-eng@lists.fedoraproject.org