Re: Find out aim of your Anaconda changes

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, [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