Re: Changing Anaconda Installation Source Spoke GUI

Replying inline,

On 05/04/2018 03:51 AM, [email protected] wrote:
> Hello Pat,
>
> On Tue, 2018-04-24 at 14:12 -0500, Pat Riehecky wrote:
>> 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.
> Could you please point us to screenshots of your addon? I think it
> would help us to get better overall idea of what are you trying to
> achieve here.

Can do,

I've attached three screenshots:
- context.png is our existing SL addon
- NewInstallSpoke.png is what I'm proposing we leave on the Install 
Media spoke
- NewSpokeUI.png is what I'm proposing for the new UI spoke


>> == 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.
> This is a UX problem and it would be nice to solve.
>
>
>> 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
> This may be solved by some of the changes we are making right now. See
> below.
>
>> == 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.
> Wouldn't it result in empty spokes? Spokes which have only a few text
> fields really don't look nice.

I'm hopeful that .treeinfo will have a few things to toss into the new 
spoke.

Also, the new ability to add repos via installclass, should help put 
more bits into the window.

>> === 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' ?
> What is the purpose of this. Which repositories you want to enable by
> this? On the installation media or repositories from the inst.repo
> command?

This is really targeted at Fermi and CERN usage, but could have wider 
appeal.  I'm generically thinking OpenStack could provide a custom 
boot.iso that automatically enables the relevant CentOS SIGs via a 
simple change to isolinux.cfg.

We've each got our own Site Specific repos that setup things like 
Kerberos, ssh, and system inventory.

Each of us ships a custom install image that add this repo and enables 
it.  I'd prefer a simple change to to the isolinux.cfg (Fermilab 
current) rather than changing base repo and shipping a custom 
updates.img to populate and activate the installclass repos (CERN current).

Quick example ISOs:
Normal SL7 boot.iso: 
http://ftp.scientificlinux.org/linux/scientific/7.4/x86_64/iso/SL-7.4-x86_64-netinst.iso
Fermilab SL7 boot.iso: 
http://ftp.scientificlinux.org/linux/scientific/7x/contexts/fermilab/images/SL-7.4-fermilab-x86_64-netinst.iso

The only real difference between them is isolinux.cfg.  I've got a 12 
line shell script that uses 'genisoimg graft-points' to make the change.

>> == 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.
> Definitely chopping this to smaller sizes is necessary. Plenty of that
> code is history and some pieces could be hard to modify. Side benefit
> is that smaller PRs will result in quicker response from our side :).
>
>
> In overall we are now working in moving Anaconda to modular system.
> Which will result (and already did) in plenty of rewriting. We already
> moved most of the kickstart commands processing to modules and change
> those calls from UI spokes to these modules. We will continue and our
> great goal is to simplify logic in UI and move it to the modules. So UI
> basically should have much less complexity and should be easier for
> changes.
>
> The reason I'm mentioning this is that I like your solution. It won't
> be that easy to achieve but most of those points would be beneficial
> for all users which is great.
> However, thanks to our work now, it is probable that your changes you
> want to do will be rewritten by us later. I really like your passion
> and I don't want to discourage you, I only think we should wait at
> least when the Source spoke logic will be moved to modules and
> cleaned. When that happen we can start discussion with details how to
> implement those pieces. In that time the payload module API won't be
> set in stone so we can add/modify what is needed before we make it
> stable. You can help us with the modules API definition.
>
> Jirka

That makes a lot of sense, is there a tracking bug/workflow/todo/design 
doc/etc I can read up on beyond these?[1]

I can see about trying to get some ideas/design/code/etc into place 
based on what is going on there, but I'd need to get up to speed on dbus 
and the existing API thoughts/definitions/best practices/etc.

Not discouraged,

Pat


[1] https://rhinstaller.wordpress.com/2017/10/09/anaconda-modularisation/
https://rhinstaller.wordpress.com/2017/11/23/anaconda-modularization-install-classes-and-addons/
https://rhinstaller.wordpress.com/2018/02/07/what-is-the-next-step-in-anaconda-modularization/
https://fedoraproject.org/wiki/Changes/AnacondaModularization

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