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@xxxxxxxx> > > 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 > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__path_to_epel-2Drelease&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=UnmKUfJU6kp9zlBGyWxQzGG6jUOK_43CBfnGcGPIeMg&e= > > > 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_anaconda-2Ddevel-2Dlist_2018-2DApril_msg00010.html&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=s8N8QONc2RgQgsM2LYw_mBNrFuPeNnne0FWj2dOqoMY&e= > > > [B] > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_7x_contexts_&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=vN5C40-kolz3ypKa5Snrbw_x2lh6vAv-nS7uFsdM1eA&e= > > > [C] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants_&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=B7gpgHz0_xEmaBMU3fvzo-21upSmbjUMJLrz2efrO9c&e= > > > [D] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_SpecialInterestGroup_PaaS_OpenShift-2DQuickstart&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=Z4St0Wt-Esz0_KXk_ZG5Tpmy5B9yo_RmOJsNfQjunK8&e= > > > [E] > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node.html&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=5JZla9bCV7z1eZCyAavlBx363er2A7_d0R9sBSLJKuA&e= > > > [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 > > > > > > > -- > > > Pat Riehecky > > > > > > Fermi National Accelerator Laboratory > > > http://www.fnal.gov > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scientificlinux.org&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=oEejHKEE_MsC13CkCdUT4HadHy8ZumBaE5RlLmRJ8QQ&e= > > > > > > _______________________________________________ > > > Anaconda-devel-list mailing list > > > Anaconda-devel-list@xxxxxxxxxx > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_anaconda-2Ddevel-2Dlist&d=DwICAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=9HG3dzq2CiSOP5uEFvIVfmvUNpe0bYrpZJY5lzy5HhQ&s=O4Y2R6I6SufCv_YGaCnS0cXgDSv2wFt7b0BYLWYs55E&e= _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
