Anaconda-devel April 2018

anaconda-devel@lists.stg.fedoraproject.org

5 participants
4 discussions

Changing Anaconda Installation Source Spoke GUI
by Pat Riehecky 20 Sep '18

20 Sep '18

Hello Anaconda folks, I'd like to get a conversation going about the Installation Source Spoke GUI. If this looks viable, I can do a lot of the non-i18n of the work. But I'd like to test out the thoughts before diving into the code. My biggest need is to show users there are other repos they could activate. This conversation is really about the UI workflow (inspired by PR#1323). I've got an addon that does a fair job of showing these to users, but I'd rather get some of my behavior upstream instead of continuing to port the SL anaconda addon. == Background == The Spoke GUI is trying to do two actions: 1. Locate the install tree 2. Configure additional repositories The TUI Spoke is only trying to do (1.) Locate the install tree. I like the GUI layout of - 1. Locate the install tree. All of that looks great and works for me and my user base and is consistent between TUI and GUI. It is the second one - 2. Configure additional repositories - that I'd like to reimagine. It is only available within the GUI. Configure additional repositories is itself divided into two behaviors: A. Enable/Disable updates.repo B. Create other repos for use Behavior A. "Enable/Disable updates.repo" has an obvious use case. Behavior A. is visible to: - Fedora - Scientific Linux Behavior A. repo can be enabled/disabled via the InstallClass. Behavior B. "Create other repos for use" is used to add additional repos such as ELRepo or EPEL (under EL builds) or Addons such as HA. Behavior B. is visible to: - Fedora - RHEL - CentOS - Scientific Linux - Springdale Linux - Etc Behavior B. is populated with entries from .treeinfo under: - RHEL ISO 7 (High Availability, Resilient Storage) - Scientific Linux 7 (Bugfixs, Extras, Repos) - Springdale Linux 7 (Computational, Updates, Addons) The Behavior B. repos are disabled by default. Additional repos can be seeded by the InstallClass now too. == Problem == P1. If you don't have an install tree specified, when you click on "Installation Media", there are no extra repos listed. This means the workflow for enabling the Behavior B. repos for a netinstall with no set install tree is as follows: Step 1. Click on "Installation Media" and set the install tree Step 2. Click done to validate the install tree Step 3. Click on "Installation Media" again to review additional repos The User Experience for Step 3 here is unexpected. P2. Folks who are looking for the Additional repos don't click on "Installation Media" to look for them. If install media is found and working, my users don't expect to find them under a "Media" item. With nothing broken and nothing requiring interaction, they just don't click it. . The RHEL7 addons are on the media, but users are unaware . With the liner install from "old anaconda" users saw these repos . Fedora could possibly put the Cisco H264 and modularity repo here . As an SL maintainer I'd like users to see the repose we've added . I assume the Springdale folks would also like the higher visibility . The CentOS SIGs could be listed here where folks could see them P3. Repos imported from .treeinfo/InstallClass have no clear way to be automatically activated by the InstallClass. . SL updates are in 'security' and 'fastbugs' repos, not just 'updates' . CERN folks expect some packages to be loaded from a specific repo == Existing Solutions == anaconda-addon-org_scientificlinux_contexts (Solves P2 and P3) The lack of clicks on "Installation Media" was a major driver for creating the Scientific Linux Context Anaconda plugin. I am the primary maintainer of this addon. updates.img (Solves P3) The CERN folks have an updates.img that forces the CERN repo into the installroot, activates it, and adds a hook in firstboot (locmap) to tweak settings. == Proposal == === UI Workflow (Solve P1 and P2) === Move Action 2. "Configure additional repositories" into a separate Spoke. Basically this is just chopping sourceWindow in half and moving the behavior to another (non-mandatory) Spoke. (from pyanaconda/ui/gui/spokes/installation_source.glade) I propose the name "Additional Software". I'd like to talk about moving "Install Updates" over here as in this workflow "Updates" becomes yet another repo. Having it activated by default for Fedora and SL feels like a solvable programming problem. === Automatic Activation Workflow (Solve P3) === Add a flag for `/proc/cmdline` that can be set multiple times. Maybe `inst.enable.repo=XXXX` where XXXX is the repo 'id' ? == Followup Thoughts == The User Experience outlined in P1 isn't ideal. You can sorta test it with the CentOS7-1708 net install media. pyanaconda/ui/gui/spokes/installation_source.py#414 suggests the code needs work. Chopping the size of that task up a bit may simplify this down the road. Pat -- Pat Riehecky Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

4 6

Adopting CoreOS Ignition into Fedora+derivatives ecosystem
by Colin Walters 20 Apr '18

20 Apr '18

We're working on merging some of the CoreOS <https://coreos.com/> technologies with the Fedora/Atomic technologies. One thing that came up is they have a new take on system bootstrap called Ignition: https://github.com/coreos/ignition We're investigating making this work in Fedora as well: https://pagure.io/atomic-wg/issue/450 There's a fair amount of overlap with the role of Anaconda in terms of system provisioning. Some of this is actually similar to the overlap between kickstart + cloud-init I posted previously: https://www.redhat.com/archives/anaconda-devel-list/2014-December/msg00008.… We're currently thinking Ignition should take over from cloud-init (though the details there are still TBD). Its ability to do partitioning makes it a lot closer to kickstart[1]. One thing I'd floated in some of our discussions was that conceptually one could write a kickstart-to-ignition transpiler just like the "clc-to-ignition" transpiler: https://coreos.com/os/docs/latest/overview-of-ct.html I'm not sure if this would be valuable versus writing ct since most people are going to be starting "fresh" I suspect, but the fact that we could helps understand the concepts here I think. Probably where the biggest overlap is around baremetal provisioning; CoreOS supports a "PXE-to-Live" model for servers: https://coreos.com/os/docs/latest/booting-with-ipxe.html as well as a script to install to disk persistently: https://coreos.com/os/docs/latest/installing-to-disk.html The latter path is like the existing Anaconda+kickstart path; so where things intersect most strongly here is what we do with those two paths. I'd suggest that for PXE-to-Live which we don't currently productize that we focus on Ignition. For persistent installations - I think we'd clearly need to support kickstarts, but it's probably useful to look at a path where Anaconda includes support for Ignition; perhaps it something like a %ignition config stanza in kickstart? [1] They even support partitioning the root filesystem but I think that only works for the existing CoreOS with the dual-partition /usr A/B approach; what I call "classic" Fedora with yum as well as the existing Atomic with rpm-ostree both have the operating system content in /, not in separate partitions.

2 3

Installer support for flatpak
by Matthias Clasen 17 Apr '18

17 Apr '18

Hi, I would like to discuss flatpak support for anaconda. The issue comes up in the context of Atomic Workstation and rpm-ostree. Currently, the OS image contains a bunch of preinstalled desktop applications (as rpms). It would make a lot more sense to move to installing all desktop applications as flatpaks, so they are independent from the OS. For preinstalled apps, that means anaconda may have to learn a bit about flatpak. We are aiming to have flatpaks built in Fedora infrastructure well before F29, and that would be the time when we can consider preinstalling them. When I talked to Colin about this before, he suggested a few steps for this: 1) Make the flatpak command work in %post 2) Add a flatpak repository to the iso Is there anything else that is needed ? Matthias

3 3

Overriding Addons in Anaconda
by Gabe Alford 03 Apr '18

03 Apr '18

Hello, I was wondering if there is a way to get/modify a list of Addons from another Addon in Anaconda, or if there is a way that I can get the %addon sections of another Addon? Basically, I would like to create an addon that can disable the kdump addon or any addon from a provided list.

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel April 2018