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: > > 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@xxxxxxxxxx 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: > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rhinstaller_anaconda_pull_1949&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=5EYJaoabMw_R0u9rdI-0hAyYUYgtdKFSTURCMqTukhc&s=UfZIRm_3zRGHnLJOOKiLSmXbF_hsp-3Yxveg95YLNuk&e= > > [2]: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rhinstaller_anaconda_pull_1690&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=5EYJaoabMw_R0u9rdI-0hAyYUYgtdKFSTURCMqTukhc&s=ydEsNP2igh2N37Uvzbq3saIhVNo7XUSDyTU5rXU9BJQ&e= > > > > Thanks a lot for your contributions, > > Jirka > > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
