Re: Changing Anaconda Installation Source Spoke GUI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If you are looking to play with anaconda for improvements. Here is one that is more than cosmetic.
My scenario -- 5 disks FedoraGnome, Fedora KDE, Mate,Cinnamon and a test drive for Rawhide.
On clicking to present the disks, anaconda does a full scan of each drive. That scan takes a looonnng time.
Why not just present some basic information a la blkdid  and after I choose my drive(s), then
do the detailed scan of those.  A four or five minute thumb twiddling wait period could be dropped to
about 45 seconds or less.


Regards

 Leslie
Leslie Satenstein
Montréal Québec, Canada



On Tuesday, September 4, 2018, 12:38:07 p.m. EDT, Pat Riehecky <riehecky@xxxxxxxx> 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
>
> On Tue, Apr 24, 2018 at 9:12 PM, Pat Riehecky <riehecky@xxxxxxxx> 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.
>>
>> == 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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux