Changing Anaconda Installation Source Spoke GUI

[Pat Riehecky]

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

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.
> == Background ==
> The Spoke GUI is trying to do two actions:
> Locate the install tree
> 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.
> === 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?
> == 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

[Pat Riehecky]

Replying inline,

On 05/04/2018 03:51 AM, [e-mail] 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:
> > Locate the install tree
> > 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...
Fermilab SL7 boot.iso: 
http://ftp.scientificlinux.org/linux/scientific/7x/contexts/fermilab/images/...

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...
https://rhinstaller.wordpress.com/2018/02/07/what-is-the-next-step-in-anacon...
https://fedoraproject.org/wiki/Changes/AnacondaModularization

[Vendula Poncova]

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  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:
> Locate the install tree
> 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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Pat Riehecky]

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  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:
> > Locate the install tree
> > 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
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Leslie S Satenstein]

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), thendo the detailed scan of those.  A four or five minute thumb twiddling wait period could be dropped toabout 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  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  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
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi Pat,

Lots of Anaconda code is migrated to the new solution but right now we
are swamped by plenty of other more priority work, so we weren't able
to migrate core parts yet.

We are still missing for example payload, install classes and flags.
Right now Vendy (vponcova) is working on porting Storage to a module
which is a difficult task thanks to the storage library and all the
supported remote devices.

If you want you can look on the code to get familiar with the changes
but it will still change a lot in the future.

Jirka

On Tue, 2018-09-04 at 11:37 -0500, Pat Riehecky 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 
> > 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:
> > > Locate the install tree
> > > 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
> > > [e-mail]
> > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list
> >
> > Anaconda-devel-list mailing list
> > [e-mail]
> > https://www.redhat.com/mailman/listinfo/anaconda-devel-list