Re: Find out aim of your Anaconda changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
Pat Riehecky

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

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux