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
