Re: Find out aim of your Anaconda changes

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, [email protected] 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:
>>
>> 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=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=5tbV47qXtPiMIm9qZehebotBe15NSQ2EJ3mKeUIZ82U&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=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=WOk1pR-5aIzbdHPW7byQ8KefP4oW6TssK0_uuGt7TsM&e=
>> [B] https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org_linux_scientific_7x_contexts_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=F6zZGFyTlEC1R4Kd9K8PEB-6a-NlzD2aXeSi4n8mqd0&e=
>> [C] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.centos.org_variants_&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=gvdmlzVhPlZfoRdiZMuXk98BEiU3Rp3nqAmERjwr7Io&e=
>> [D]
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_SpecialInterestGroup_PaaS_OpenShift-2DQuickstart&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=Ptz3dNkPBDyAuWCuqOAIsbnJUEc6qZAHkDvuRDgEMYs&e=
>> [E] https://urldefense.proofpoint.com/v2/url?u=https-3A__ovirt.org_download_node.html&d=DwICaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=jAPw79p2dAkYzh9ZFRuTJ5sF0LsaWoOoTV1qcQNDFhc&s=IeJImRsGpW5jjtXUtIgb-Z0dzOVXlF3B_ns-IK4rP3o&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
www.fnal.gov
www.scientificlinux.org

_______________________________________________
Anaconda-devel-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/anaconda-devel-list