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

[master] Repository setup and UI patches.

 data/ui/addrepo.glade         |    1 +
 pyanaconda/__init__.py        |    3 +-
 pyanaconda/backend.py         |    9 +-
 pyanaconda/dispatch.py        |    5 +-
 pyanaconda/gui.py             |    2 +-
 pyanaconda/image.py           |   45 --
 pyanaconda/installclass.py    |    5 +-
 pyanaconda/iutil.py           |   13 +
 pyanaconda/iw/task_gui.py     |  624 ++++++++---------------
 pyanaconda/kickstart.py       |    8 +-
 pyanaconda/text.py            |    2 +-
 pyanaconda/textw/task_text.py |    1 -
 pyanaconda/upgrade.py         |    1 +
 pyanaconda/yuminstall.py      | 1112 +++++++++++++++++++++++------------------
 14 files changed, 885 insertions(+), 946 deletions(-)

This patchset aims to reorganize our repository editing UI flow so that:

- we don't need hacks to reset repos/sacks of YumBase object when going
  back, rather use new YumBase object see [1]
- we can handle some errors during configuration more gracefuly
  see [2], [3] with screencasts
- we can offer a NFSISO (this one is in the patches) and HD for
  base/installation repo in editing UI quite easily
more generally speaking:
- the code is more comprehensible, maintainable, and less prone
  to fallouts rooted in using yum internals in ways not expected
  by yum (yes, hacks)
- base/install repository is handled the same way as other where

The patchset does not:
- change UI layout, I think it needs proper design
- abstracts repository/packages source completely, but moves things
  in this direction

The trick is to move tasksel step (repo editing + task selection) before
reposetup step and introduce new repocollect step preceeding tasksel in
which all repo specifications are collected (from method, ks, dd,
/etc/anaconda.repos.d) into objects of new class RepoSpec stored in
anaconda.repos list.  RepoSpec objects can be used in UI (and elsewhere,
e.g.  in writeconfig) instead of AnacondaYumRepo (child of
YumRepository) objects, using of whose made UI and logic interwined to
the point of unmaintenablity. It also alows to remove stuff added into
our AnacondaYumRepo (keeping only refernce to RepoSpec there).

RepoSpec should go to its own module repos.py as it should be backend
independent.  For now, I keep it in yuminstall.py together with YumRepoSpec
which is inherited from RepoSpec.

There is one problem I don't address in this series of patches: The tasksel
step/screen combines repo editing and task selection which is unfortunate
because task selection requires all repositories to be set. The appropriate
steps would be:

edit repositories (UI) -> setup repositories (nonUI) -> select tasks (UI),

but the first and the third are on the same screen in present UI and
threfore I have to call non-UI step from the UI screen which I wasn't
able to do without hack. Making task selection a separate step or adding
it to group/package selection screen (where it belongs from the yum
backend point of view, not sure if also from user point of view) would
make things cleaner and allow to avoid the UI flow hacking (see (*) in
steps 2) and 3) in "Patched flow" below) You can see in [4] how the
repositories are setup after each modification in repo list.

Another important change is that all the repository setup (network enablement,
mounting, repo setup, sack setup, groups setup) is done in a loop over all
enabled RepoSpecs which allows for better handling of errors in UI.

Some overwhelming details:

Present flow:

1) "reposetup" step 
   - create ayum (YumBackend object)
   - add AnacondaYumRepo objects for required repos (mehtod, ks repo=, dd)
     and add them to ayum object
   - mounting of isos (for cdrom, nfsiso, hdiso)
   - network enablement if needed
   - repo setup, sack setup, group setup
   - editing of invalid repos in dialog - no way
     to disable repo at this point, in case of
     fail only Edit/Exit is offered
2) UI "tasksel" step
   - edit repos - working directly YumRepository objects (the ayum.repos
     is the only store of repos we have), so all setup from step 1)
     has to be done here too
   - select tasks (note that changes in repos can make task selection
     list obsolete in theory)
3) "basepkgsel" step
   - group/package selection based on installclass and ks
   - hacky resetting of groups/sack information
     needed for going back in UI (from 4, from dialog in 5)
4) UI "group-selection" step
   - you can go back to 2)
5) "postselection"
   - create transaction
   - in case of conflicts you can go back to 4) from a dialog
6) "writeconfig"
   - write anaconda-ks.cfg using ayum.repos (AnacondaYumRepository

Patched flow:

1) "repocollect" step
   - initialze RepoSpec objects storing specs of required repos
     (from method, ks, DD, /etc/anaconda.repos.d, addon repos for RHEL)
2) UI "repotasksel" step (formerly "tasksel", keeping its UI layout)
   - edit repos - works on RepoSpec objects
   - select tasks
   - after a repo is edited/enabled/disabled, step 3) has to be
     called so that task list can be updated
3) "reposetup" step
   - is skipped if we did it as a part of 2) in UI
     This could be removed if task selection was separated
     from repo editing (*)
   - create ayum (YumBackend object)
   - for each repo RepoSpec:
     - enable network if needed
     - mount repo (nfsiso, hd, cdrom)
     - add corresponding YumRepository object to ayum
     - set cache for repository
     - do repository setup
     - do sack setup
     - do group setup
     if any of the above fails, we know what repo was the cause of
     fail, store failure info in its RepoSpec object, go back to 2),
     mark failed repo in the list (see [4])
4) "basepkgsel" step
   - group selection based on installclass and ks
   - no reset on the way back is needed as in UI step 2),
     we start with new ayum object
5) UI "group-selection"
   - you can go back to 2)
6) "postselection"
   - create transaction
   - in case of conflicts you can go back to 5) from
     a dialog
7) "writeconfig"
   - write anaconda-ks.cfg using anaconda.repos (RepoSpec objects)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=622376#c5
    - the bug:
    - fixed with patches:

[2] if failing nfs repo= is used in kickstart
    - choosing Continue lead to fatal fail:
    - choosing Edit and Cancel lead to fatal fail:
    ... also the true cause (nfs mount error) is hidden
    - with the patch [Edit] means going to repo UI screen
      where the failing repo can be disabled:

[3] network requiring repository set by boot param repo=, no
    network needed till repository steps
    - failing to enable network for base repository is fatal:
    - with patch, you can fall back to media (non network) repo:

[4] http://rvykydal.fedorapeople.org/repoUI/example.ogg

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