On Tuesday, September 4, 2018, 12:38:07 p.m. EDT, Pat Riehecky <riehecky@fnal.gov> wrote:
Hello,
Just checking in here. Is enough of the dbus work done here for me to
start playing about with the code?
Pat
On 05/04/2018 05:52 AM, Vendula Poncova wrote:
> Hi,
>
> thanks for interesting ideas! I like the suggested UI changes for P1
> and P2. I think it makes sense to separate additional repositories
> from the installation source. However, I am not so sure about the
> solution for P3. Shouldn't the install class enable the repositories?
>
> We plan to move the logic for the installation source on DBus soon.
> All big changes should be probably done after that.
>
> Vendy
>
>> 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
>>
>> _______________________________________________
>> Anaconda-devel-list mailing list
> _______________________________________________
> Anaconda-devel-list mailing list
--
Pat Riehecky
Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
_______________________________________________
Anaconda-devel-list mailing list