Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
1) Are you planning to have an Anaconda addon which will use our DBus API?
2) Are you planning to branch SC from Fedora or only from RHEL?
3) I know you want to have EPEL repository disabled by default in the source spoke but how do you want to achieve this state?
4) Is there something else you want to change from the default Anaconda behavior?
[1]: https://github.com/rhinstaller/anaconda/pull/1949 [2]: https://github.com/rhinstaller/anaconda/pull/1690
Thanks a lot for your contributions, Jirka
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
1) Make it easier for users to install packages from EPEL (such as the Cinnamon or KDE desktops) at install time.
2) Allow users to select their desired variant/spin (e.g., Fedora Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
3) Make it easier for users to enable some extra repos the distribution trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
--- Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install http://path/to/epel-release sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
--- Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system-roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
--- Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default: - centosplus - fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00010.html [B] http://ftp.scientificlinux.org/linux/scientific/7x/contexts/ [C] https://www.centos.org/variants/ [D] https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Quickstart [E] https://ovirt.org/download/node.html [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
-- --
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our DBus
API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in the
source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default Anaconda
behavior?
Thanks a lot for your contributions, Jirka
Hi Pat,
I must say that you have a big and interesting goals. We need to sit down and think about that.
I just want to say you that we have holidays in Czech from tomorrow to Monday so there will be a delay before we find a time to do that.
Have a great weekend and thanks for the reply, Jirka
On Wed, 2019-04-17 at 14:57 -0500, Pat Riehecky wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such as
the Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the
distribution trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install http://path/to/epel-release sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system- roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00010.html [B] http://ftp.scientificlinux.org/linux/scientific/7x/contexts/ [C] https://www.centos.org/variants/ [D] https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Quickstart [E] https://ovirt.org/download/node.html [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our
DBus API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in
the source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default
Anaconda behavior?
Thanks a lot for your contributions, Jirka
No worries, I'd expect it will take a while to digest all of this and see which bits really fit in with the anaconda project mission - and how.
Word Count says it is nearly 2000 words after all. And then there are the questions that implementation ideals raise, and then the maintenance questions, and then... and then ....
Pat
On 4/18/19 10:49 AM, jkonecny@redhat.com wrote:
Hi Pat,
I must say that you have a big and interesting goals. We need to sit down and think about that.
I just want to say you that we have holidays in Czech from tomorrow to Monday so there will be a delay before we find a time to do that.
Have a great weekend and thanks for the reply, Jirka
On Wed, 2019-04-17 at 14:57 -0500, Pat Riehecky wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such as
the Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the
distribution trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install https://urldefense.proofpoint.com/v2/url?u=http-3A__path_to_epel-2Drelease&a... sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system- roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives... [B] https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_... [C] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants... [D] https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... [E] https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node... [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our
DBus API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in
the source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default
Anaconda behavior?
Thanks a lot for your contributions, Jirka
Hi Pat,
Just wanted to let you know that I will be at Summit this year. I manage the installer team and can definitely meet up with you. You're right that there won't be a detailed text trail to reference later, but it's always helpful to meet up with users and customers, so I'd be glad to chat. :) You definitely have some interesting ideas, and it's really useful to see the use cases/stories you've provided as well -- very well thought-out. This is exactly the kind of thing that helps us with our long-term planning for the project. That said, apologies that we still have not provided a detailed reply to you yet. We're a bit pinched for time lately, but rest assured that it has not fallen off our radar.
Feel free to contact me off-list to exchange contact info.
Thanks,
On Wed, Apr 17, 2019 at 3:58 PM Pat Riehecky riehecky@fnal.gov wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such as the
Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the distribution
trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install http://path/to/epel-release sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system-roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00010.html [B] http://ftp.scientificlinux.org/linux/scientific/7x/contexts/ [C] https://www.centos.org/variants/ [D] https://wiki.centos.org/SpecialInterestGroup/PaaS/OpenShift-Quickstart [E] https://ovirt.org/download/node.html [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our DBus
API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in the
source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default Anaconda
behavior?
Thanks a lot for your contributions, Jirka
-- Pat Riehecky
Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
For folks following along at home,
Samantha, Lars, and I had a really productive conversation at Summit!
I think we developed a few ideas from there.
Those ideas have a bit of work needed to turn them into proposals, which will then need some review, which will then need .... you get the idea.
Pat
On 4/26/19 8:38 AM, Samantha Bueno wrote:
Hi Pat,
Just wanted to let you know that I will be at Summit this year. I manage the installer team and can definitely meet up with you. You're right that there won't be a detailed text trail to reference later, but it's always helpful to meet up with users and customers, so I'd be glad to chat. :) You definitely have some interesting ideas, and it's really useful to see the use cases/stories you've provided as well -- very well thought-out. This is exactly the kind of thing that helps us with our long-term planning for the project. That said, apologies that we still have not provided a detailed reply to you yet. We're a bit pinched for time lately, but rest assured that it has not fallen off our radar.
Feel free to contact me off-list to exchange contact info.
Thanks,
On Wed, Apr 17, 2019 at 3:58 PM Pat Riehecky riehecky@fnal.gov wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such as the
Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the distribution
trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install https://urldefense.proofpoint.com/v2/url?u=http-3A__path_to_epel-2Drelease&a... sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system-roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives... [B] https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_... [C] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants... [D] https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... [E] https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node... [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our DBus
API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in the
source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default Anaconda
behavior?
Thanks a lot for your contributions, Jirka
-- Pat Riehecky
Fermi National Accelerator Laboratory http://www.fnal.gov https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scientificlinux.org&...
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...
On Mon, 2019-05-13 at 10:29 -0500, Pat Riehecky wrote:
For folks following along at home,
Samantha, Lars, and I had a really productive conversation at Summit!
I think we developed a few ideas from there.
Those ideas have a bit of work needed to turn them into proposals, which will then need some review, which will then need .... you get the idea.
Pat
That's great Pat. I didn't talked to Samantha yet but I'm looking forward to hear about your discussion.
And sorry that I didn't replied to your original mail yet. I was ill for the last week :(.
Jirka
On 4/26/19 8:38 AM, Samantha Bueno wrote:
Hi Pat,
Just wanted to let you know that I will be at Summit this year. I manage the installer team and can definitely meet up with you. You're right that there won't be a detailed text trail to reference later, but it's always helpful to meet up with users and customers, so I'd be glad to chat. :) You definitely have some interesting ideas, and it's really useful to see the use cases/stories you've provided as well -- very well thought-out. This is exactly the kind of thing that helps us with our long-term planning for the project. That said, apologies that we still have not provided a detailed reply to you yet. We're a bit pinched for time lately, but rest assured that it has not fallen off our radar.
Feel free to contact me off-list to exchange contact info.
Thanks,
On Wed, Apr 17, 2019 at 3:58 PM Pat Riehecky riehecky@fnal.gov wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such
as the Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the
distribution trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install https://urldefense.proofpoint.com/v2/url?u=http-3A__path_to_epel-2Drelease&a... sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system- roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives... [B] https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_... [C] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants... [D] https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... [E] https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node... [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use
our DBus API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default
in the source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default
Anaconda behavior?
Thanks a lot for your contributions, Jirka
-- Pat Riehecky
Fermi National Accelerator Laboratory http://www.fnal.gov https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scientificlinux.org&...
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...
On 5/13/19 10:50 AM, jkonecny@redhat.com wrote:
On Mon, 2019-05-13 at 10:29 -0500, Pat Riehecky wrote:
For folks following along at home,
Samantha, Lars, and I had a really productive conversation at Summit!
I think we developed a few ideas from there.
Those ideas have a bit of work needed to turn them into proposals, which will then need some review, which will then need .... you get the idea.
Pat
That's great Pat. I didn't talked to Samantha yet but I'm looking forward to hear about your discussion.
And sorry that I didn't replied to your original mail yet. I was ill for the last week :(.
Jirka
No worries, hope you are feeling better!
Pat
On Mon, 2019-05-13 at 10:29 -0500, Pat Riehecky wrote:
For folks following along at home,
Samantha, Lars, and I had a really productive conversation at Summit!
I think we developed a few ideas from there.
Those ideas have a bit of work needed to turn them into proposals, which will then need some review, which will then need .... you get the idea.
In cases like this nothing beats meeting face to face - sounds good! :)
Pat
On 4/26/19 8:38 AM, Samantha Bueno wrote:
Hi Pat,
Just wanted to let you know that I will be at Summit this year. I manage the installer team and can definitely meet up with you. You're right that there won't be a detailed text trail to reference later, but it's always helpful to meet up with users and customers, so I'd be glad to chat. :) You definitely have some interesting ideas, and it's really useful to see the use cases/stories you've provided as well -- very well thought-out. This is exactly the kind of thing that helps us with our long-term planning for the project. That said, apologies that we still have not provided a detailed reply to you yet. We're a bit pinched for time lately, but rest assured that it has not fallen off our radar.
Feel free to contact me off-list to exchange contact info.
Thanks,
On Wed, Apr 17, 2019 at 3:58 PM Pat Riehecky riehecky@fnal.gov wrote:
Hello,
I'll see if I can explain my goals and what I'm hoping to achieve/make easy. I will also be at Summit this year if any folks want to meet up for a chat or I might be able to setup a conference call - that may be easier. But that doesn't have the helpful listserv archives...
The anaconda addon I'm currently playing with is targeted at Fedora (31?) but, if it works out, I'm likely to try and get it into shape for any EL8 build.
My hope long term is to make use of the DBus API, but I'm still getting the hang of that...
I'm targeted entirely at the DNF payload for now, but I'm interested in the rpm-ostree one as well. I've just never found the time to really explore rpm-ostree in this manner.
As for my vision for what I'm aiming to achieve, I'm hopeful to get Anaconda able to account for these usage patterns during install:
- Make it easier for users to install packages from EPEL (such as the
Cinnamon or KDE desktops) at install time.
- Allow users to select their desired variant/spin (e.g., Fedora
Scientific, Silverblue, Fedora Astronomy, Fedora Design Suite, CentOS oVirt, CentOS HPC etc.) within Anaconda at install time.
- Make it easier for users to enable some extra repos the distribution
trusts for general use and have others available but disabled by default. Users may or may not want those repos.
I tend to get drawn to .treeinfo as a place where the "installation" talks about what it knows and who it trusts.
To illustrate points 1-3, I have some user stories / generic ramblings on behavior I've seen.
-- Summation of thoughts on EL side
In many ways one of my strong desires on the EL side is being able to take ##.0 media point it at a ##.10 install tree and have anaconda say "Hey I found these variants and these repos that may or may not have existed X years ago, but you can just use them."
-- Summation of thoughts on the Fedora side
Spins are neat; Labs has cool stuff. Users may not be aware or know how to get what they want. One boot.iso that does all that and maybe either RPM or OS-Tree could help curious folks try various things without having to make extra media.
Story 1: Desktop Environments
This story is about our EL users.
A large number of our workstation users have a strong preference for Cinnamon Desktop or KDE. With RHEL7, Cinnamon is packaged up in EPEL. With RHEL8, I believe there are folks planning to get Cinnamon and KDE into EPEL8. This is great!
However, I'd like to simplify things for folks doing the installation. The initial plan was to just add EPEL as a disabled repo and instruct users on how to click to enable EPEL. Then they would see the Cinnamon Desktop group in the UI. These folks are not often interested in Linux administration, but require root access for custom kernel driver development, installation of unpackaged sources, or building/running containers/VMs.
The main goal here is to provide a clear non-technical workflow for "How do I get Cinnamon Desktop when I install my system?"
The current SL7 workflow is: open a terminal sudo yum install yum-conf-epel sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
For CentOS7 the workflow is: open a terminal sudo yum install https://urldefense.proofpoint.com/v2/url?u=http-3A__path_to_epel-2Drelease&a... sudo yum install @cinnamon-desktop logout select Cinnamon Session in GDM login
Whereas, If the repo is listed under Software Sources (behavior from the reverted bit) the workflow would be: Click on Software Sources Check the box next to EPEL Click on Software Selection (which is automatically marked for review when you change Software Sources)
On my test node, Cinnamon Session was the default if you use the yum group from Anaconda.
If users are installing off of a DVD (Not Live Image) and not on the network, EPEL will not be available. So, EPEL shouldn't be enabled by default to permit offline installations. Anaconda is currently smart enough that if I add a repo requiring the network but do not have a network connection "all the right stuff" happens. EPEL is external, so disabled generically feels like the right default anyway.
I like a lot about the reverted workflow. I think it provides a clean user experience. Getting folks to click on Software Sources is achievable but that is also a workflow I'd like to optimize.[A]
Specifically on my last patch, I can drop EPEL into the .treeinfo Addons if I can get it disabled by default. I'm chatting with the .treeinfo folks about a small extension to the format there.
Story 2: Switching Product Variants/Spins/Contexts
This story is applicable to our Fedora and SL users, with an eye on helping the CentOS community as well.
I'll start with Fedora:
There are some great Variants out there. I'm personally fond of Fedora Astronomy, Fedora Scientific, and Fedora DesignSuite. The various desktop Spins are great too, and their success has largely driven Story 1.
If you grab the net install, Anaconda shows you "Welcome to Fedora ##", with the defaults for the specific spin you selected (Workstation/Server). The spins listed on spins.fedoraproject.org all seem to have their environment groups listed under Software Selection.
But what if I've got my Fedora 29 install disk and want to install Astronomy or Scientific? There isn't a great way install a system so it looks like the Astronomy spin.
I know Astronomy from Fedora Labs is only shipped as a live image now and I've no interest in a tool that converts live to another format. It might be possible to just read the kickstart into anaconda but leave it interactive... Could help with oVirt Node or maybe rhel-system-roles.....
It is more a reflection on the fact that there are great spins out there. If I've got a Fedora Server boot.iso, I know I can use it to install Fedora MATE Spin. Users I've chatted with seem puzzled. I'd love to find a way to expose this better.
The Fedora boot.iso seems to have most of the bits required for SilverBlue (rpm-ostree). It would be neat if users could just click their from Fedora Server to Fedora SilverBlue from a single install disk.
On the SL side:
We've build an Anaconda Addon for SL Contexts.[B] It generally consists of adding a repo (or multiples), adding some packages to the payload, and kickstart snippets.
Effectively you check a box and your SL installation will automatically add the Context Spin you selected to your installation. You can pick multiple Contexts if you want.
It is dependent on network resources so that you can take some old media and still find the current list of Contexts.
From a behavior side I need to inject some repos, package groups, and packages into the payload.
Looking over at CentOS:
They proposed a plan to build up variants.[C] I'd expect there to be a few Official Variants - probably OpenStack, OpenShift, and HPC.
I've not found any dedicated install media. Right now the installation for OpenShift, for example, consists of a few manual rpm installs to add repos and then a few more to add packages.[D] I show over a dozen possible software targets produced by Special Interest Groups that follow the same pattern. Can we make this easier?
It wouldn't make sense to put the groups for each SIG into the main repo as they may change over time. New SIG variants could come into existence. Existing groups could change packages. A variant repo might depend on another repo which uses in turn another and so on.
So what would be the best way to expose this ecosystem to the user? How can we make it easy to add deployment roles for variant targets?
If there was a way to select a specific variant, have anaconda load that variant's info (repos, .treeinfo?, artwork?), you could take any CentOS ## install media (dnfpayload) and with a few clicks convert it into a specific variant. And after the install you'd have a kickstart file you could use to make live media.
My best idea right now is to have some additional bits in .treeinfo and use those bits to drive anaconda so that the makers of official install trees can say, "Hey here are some related resources you may or may not want," via metadata. Then change out the base repo to the new base repo and read that treeinfo or just toggle Addon repos.
The most immediate usage I'd expect is probably with oVirt. The oVirt Node media[E] is a very slimmed down installation for use with oVirt. It is a repackaged CentOS install disk. If this was granted "Official Variant" status it would be awesome if there was a way to just select "I want this variant" rather than pulling yet another install disk. As an asside, the oVirt repos are not hosted on a centos.org domain so that would also be a piece of the puzzle.
In general the BaseOS is great! The layered 'products' are great! Getting the users to the layers or the layers to the users.... not so great.
In a number of ways I see CentOS as being able to benefit from the SL and Fedora workflow here.
Story 3: Looking at CentOS additional repos
This story really highlights the various extra software repos CentOS is providing. Each repo is different in terms of safe default state.
CentOS has a few neat extra repos that should be disabled by default:
- centosplus
- fasttrack
Each of these repos provides packages that are replacements for the official packages. These repos exist because of user demand.
These can be exposed in .treeinfo, but only if they are disabled.
They've also got the 'CR' repo. This repo contains updates during the time period between an upstream release and the official CentOS release. Since there are generally security errata in there during this window, it would be nice to have it in .treeinfo. I'm not sure if it would make sense to have it enabled by default or not.
Then there is the CentOS 7 Extras repo. After a default install of CentOS 7, this repo is on your system and enabled. It is, however, not exposed to anaconda. This inconsistency bugs me a bit.
The C7Extras repo doesn't provide any package groups, but it does contain docker, kubernetes, and podman. It could provide a container-platform package group. Maybe that group could extend the Virt Environment group to add container support?[F] If it did, exposing it to anaconda would be a bit strange.
Since C7Extras is enabled by default once the system is installed, I'd love to pull it out of .treeinfo and enable it by default. That way the repos anaconda is using to install the system match the repos on the system once it is installed.
But we've got other repos that I think users should have simple access to, and those should probably be disabled by default.
The repo could be dropped into /etc/anaconda.repos.d/ as enabled. But what if as a user I don't want it enabled? If down the road it adds groups that extend default groups this could be an actual need.
This I've no clear idea how to solve. I'd love to have a way to do both add enabled and add disabled from some sort of workflow.
Pat
-- End Notes
[A] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_archives... [B] https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_... [C] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants... [D] https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_Special... [E] https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node... [F] Like SL7 they are following RHEL7 on this, but I personally think (and have asked RH) that those groups should exist here.
--
On 4/17/19 7:44 AM, jkonecny@redhat.com wrote:
Hello Pat,
You started to raise more and more pull requests to our Anaconda code base. I really like we have that active contributor like you, however, we have a hard time to see what you want to achieve with these changes.
It is not that trivial to test your changes and also we would like to help you to create a solution which will be beneficial for all of us. So before I'll merge your another PR[1], I would like to know more about your project.
We have a vision of what is your aim for these changes. At RHEL 7 & RHEL-8 you have an ability to add disabled addon repositories specific for your distribution, this was removed[2] with a message that we will provide you another solution how to add this back. Our changes which will make your changes incompatible are now planned to RHEL-8.2. What we are planing to have (and we need to have) is the ability to add a repository by DBus API and disable this repository by the same API afterwards. However for that, you have to have an addon. There are also other options in our aim but we have to know what you are trying to achieve first.
Could you please answer the questions below:
- Are you planning to have an Anaconda addon which will use our DBus
API?
Are you planning to branch SC from Fedora or only from RHEL?
I know you want to have EPEL repository disabled by default in the
source spoke but how do you want to achieve this state?
- Is there something else you want to change from the default Anaconda
behavior?
Thanks a lot for your contributions, Jirka
-- Pat Riehecky
Fermi National Accelerator Laboratory http://www.fnal.gov https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scientificlinux.org&...
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...
anaconda-devel@lists.stg.fedoraproject.org
-
jkonecny＠redhat.com -
Martin Kolman -
Pat Riehecky -
Samantha Bueno