Changes between Version 3 and Version 4 of Development/YumAndSPMA


Ignore:
Timestamp:
Mar 29, 2013, 3:22:20 PM (13 years ago)
Author:
munoz
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Development/YumAndSPMA

    v3 v4  
    7373>There may be cases where you really want to roll back the packages, but I think such rollback logic is really the job of a backup system instead of Quattor. If ncm-spma can be told the path to run yum, then it would be possible to create a wrapper around yum that maintains the tag/history ID mapping, without having to integrate that functionality into ncm-spma itself.
    7474
     75== Splitting up transactions ==
     76
     77So, there is a problem right now with our single-transaction behaviour.
     78
     79Imagine this dependency graph, where green nodes are in the profile, yellow ones are dependencies that are not specified directly in the profile and red nodes are nodes that shall be removed:
     80
     81
     82Both smithers and mrburns are specified directly in the profile.  But the distribution recalls that smithers depends on mrburns, so it adds a dependency. At the same time, we decide mrburns is not a critical part of our infrastructure, so we remove it from the profile:
     83
     84When the component kicks in, it looks at ''leaf'' packages that are not in the profile. Since `smithers` hasn't been updated, it runs this check against a system that looks like this:
     85
     86Thus, we'll schedule mrburns for removal. Our transaction will thus be:
     87
     88```
     89remove mrburns
     90distro-sync
     91```
     92
     93Which means this dependency graph:
     94
     95We cannot update smithers because mrburns will be removed!!  Curretly this requires manual intervention, or intermediate deployments.  Neither option is acceptable.
     96
     97Making the component discover this type of dependency with this set of steps would be error-prone.  And removing a single package would take hours, literally.
     98
     99To fix this I'd like to ensure the third situation doesn't ever happen.
     100
     101=== Running yum distro-sync at the beginning of the component ===
     102
     103The problem is that the third graph is derived from incomplete information.  What we'll do, thus, is to run `yum distro-sync` early in the component.  After this step, the component will discover that smithers cannot be without mrburns.  And it won't try to remove mrburns.
     104
     105We'll start again:
     106
     107and distro-sync will leave our system:
     108
     109and we'll be happy!
     110