Anaconda-devel September 2019

anaconda-devel@lists.stg.fedoraproject.org

13 participants
5 discussions

Proposal to use repo files in Anaconda environment
by jkonecny＠redhat.com 02 Oct '19

02 Oct '19

Hello everyone, We (the Anaconda installer team) want to solve multiple problems by one solution and we want *YOUR FEEDBACK!* In short we are proposing to use custom repo files when configuring Anaconda for image creation instead of adding even more complexity to the kickstart repo command. For more details see the link below. Purpose of this mail is to give everyone interested in the topic a place to discuss our proposal to find out if we didn't miss something or better case, if you agree with it :). It could be that this is not applicable for Lorax / Pungi / live-cd tool in that case please write a response to the document. You can read details here: https://hackmd.io/@prJIqOTeSxC-W0RNGKIGbQ/ByzIz3kIH/edit Please, all the relevant comments should stay in the document if possible. If that solution won't work because of higher traffic then we will find a better solution but the point is to have everything on one place. Have a great day everyone, Jirka

2 4

CoreOS vs Anaconda toolchain
by Colin Walters 11 Sep '19

11 Sep '19

Hi, I wanted to link this here: https://github.com/coreos/coreos-assembler/issues/91 Most importantly starting from https://github.com/coreos/coreos-assembler/issues/91#issuecomment-422830233 and the most recent ones. Would love to do some brainstorming about how we can share more code/ideas in general; I had some specific comments towards the end. One thing not explicitly noted there is how key Ignition is to FCOS (and derivatives like RHCOS) - having a common language that works in both bare metal as well as e.g. AWS and Azure is a big deal - and today the OpenShift 4 installer and the [machine-config-operator](https://github.com/openshift/machine-config-operat… are built heavily upon it.

5 5

"PRE-RELEASE/TESTING"
by Danishka Navin 11 Sep '19

11 Sep '19

Hi there, When I was trying to install f30 based remixed ISO, "PRE-RELEASE/TESTING" text appearing in top-right hand side of anaconda GUI. May I know what could cause this? both os-release and redhat-release updated and I can see given values. both fedora and fedora-update repos used during the ISO build along with few 3rd party repos. Regards, -- Danishka Navin

4 8

Discussion: what would not blocking on btrfs look like?
by Adam Williamson 10 Sep '19

10 Sep '19

Hey folks! So, there was recently a Thing where btrfs installs were broken, and this got accepted as a release blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1733388 The bug was fixed, so that's fine, but along the way, Laura said this: "I'm strongly against anything with btrfs being a blocker. If that's in the criteria I think we should see about removing btrfs simply because we don't have the resources to actually deal with btrfs besides reporting bugs upstream." and Justin followed up with: "Agreed, btrfs has been a gamble pretty much always. See previous discussion around proposals to make btrfs default. Ext4 and xfs should be the only release blocking." So, that's the whole kernel team 'strongly against' blocking on btrfs. Which means we should talk about not doing that any more! This is a bit complicated, though, because of how the Final criteria are phrased. Basic does not include btrfs at all, and Beta includes a laundry list we can just remove btrfs from: "When using both the installer-native and the blivet-gui-based custom partitioning flow, the installer must be able to: * Correctly interpret, and modify as described below, any disk with a valid ms-dos or gpt disk label and partition table containing ext4 partitions, LVM and/or btrfs volumes, and/or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions * Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions ..." so those two are easy. However, the Final criterion is not laundry list-style. The relevant Final criterion is this: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." with a somewhat apologetic explanatory footnote: "Wait, what? Yeah, we know. This is a huge catch-all criterion and it's subject to a lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is that you should be able to do anything sane that the Installation Destination spoke attempts to let you do, without the installer exploding or failing. We are trying to write more specific criteria covering this area, but it's not easy. Patches welcome, as the kids say..." so as the footnote says, the rule is basically "if the installer lets you do it, it ought to work". It seems a bit awkward to craft an exception for btrfs from that. I mean, technically it's easy: "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration, except btrfs." but that's odd. Why is btrfs, alone, an exception? It kinda goes against the fundamental idea of the criterion: that we stand behind everything the UI offers. So...what should we do? Here are the options as I see 'em: 1. Keep supporting btrfs 2. Just modify the criterion with a btrfs exception, even if it's weird 3. Rewrite the criterion entirely 4. Keep btrfs support in the installer (and blivet-gui) but hide it as we used to - require a special boot argument for it to be visible 5. Drop btrfs support from the installer I'm bringing this to anaconda, kernel and test teams initially to kick around; if we agree on an approach we should then probably loop in devel@ for wider review, unless the choice is 1). Thanks for any thoughts, folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

15 56

I'm the new maintainer of pykickstart
by Brian C. Lane 06 Sep '19

06 Sep '19

Today we created a new, permanent, location for pykickstart: https://github.com/pykickstart/pykickstart/ And I've agreed to be the new maintainer. I've been involved with Anaconda and pykickstart since I joined Red Hat in 2010 so this isn't a new experience for me :) My general philosophy for this is going to be "don't break it". I consider pykickstart to be one of the best examples of how to write a python library, especially one that has to support so many different features and versions so I have no plans to make fundamental changes. I consider it primarily to be in maintenance mode, driven by bugfixing and requests from Anaconda. Recently there have been some requests to add features to pyks for the livecd-creator project that don't have (and never will) support in Anaconda. I've been trying to come up with a way to make everyone happy -- and haven't. At the moment I think the best way to proceed is to require that new features need to have patches, and be accepted by, Anaconda. Anything else is just going to lead to a fractured user experience, confusing documentation, difficult to debug problems, etc. Since Anaconda is the primary user for pyks it makes practical sense to have the installer team's input on new features. I also will *not* be re-reviewing any old closed requests. If the previous maintainers declined to add something I am not going to re-open it. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel September 2019