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 <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@xxxxxxxxxx > > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > > _______________________________________________ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
