Re: Find out aim of your Anaconda changes

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 <[email protected]> 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, [email protected] 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
>> [email protected]
>> 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=
>
>

-- 
Pat Riehecky

Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org