Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-115867

Merge actors + refactoring: setuptargetrepos, peseventsscanner, repomapscanner (+ repositoriesblacklist?)

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • None
    • rhel-upgrades
    • 3
    • False
    • True
    • None
    • None
    • None
    • None
    • Unspecified
    • Unspecified
    • Unspecified
    • None

      As a developer, I would like to know what's going on and implement stuff properly...

      Right now, we have several fundamental actors regarding repositories and packages to discover what we would like to happen in later phases of IPU (e.g. what repositories should be used, what should be installed/removed, etc). Focusing now just on consumed and produced msgs:

      • peseventsscanner
        • consumes:
          • InstalledRedHatSignedRPM
          • RepositoriesBlacklisted
          • RepositoriesFacts
          • RepositoriesMapping
          • RpmTransactionTasks
        • produces:
          • PESRpmTransactionTasks
          • *RepositoriesSetupTasks
          • (Report)
      • setuptargetrepos
        • consumes:
          • CustomTargetRepository
          • *RepositoriesSetupTasks
          • RepositoriesMapping
          • RepositoriesFacts
          • RepositoriesBlacklisted
          • UsedRepositories
        • produces:
          • TargetRepositories
          • SkippedRepositories
      • repositoriesblacklist
        • consumes:
          • CustomTargetRepository
          • RepositoriesFacts
          • RepositoriesMapping,
        • produces:
          • RepositoriesBlacklisted
          • (Report)

      In the first two repositories we had to implement the whole decision logic around the repositories mapping, the blacklist one is kind of ok just with some simple filters, so keep the last one separated from the main goal right now.

      *What could be the advantage?*
      Recently we had to deal with problems that we our input data format could be changed in a way it affects the data format used between actors (remember the problem with the RepositoriesMap? We have RepositoriesMapping now. The original format couldn't satisfy our needs and even we haven't expected people to use it. First thing here is - that with the merge of these actors, we reduce the amount of needed models which we (let's say) expect just for our private use.

      The current implementation of these actors is already pretty complex and we have to reuse some parts of code to decide all this stuff. As you see they have a lot of common regarding data they consume. So why we are doing same work multiple-times? The final implementation doesn't have to be more complex, kind of it could be even vice versa partially. Finally, we could refactor the code so it will be readable.

      Currently, trying to explain the "main graph" where every actor is one node takes a lot of time - the most time I always spend is on explanation of these actors. Including explanation of all those models/messages they consume and produce. From my experience, people are usually pretty lost around that amount of models. I believe that having just one actor in this case it could make easier for people to understand the high-level picture. Honestly, this part of IPU is just our magic, not sure if anyone outside of our team has to understand details (and who understand all details around these actors in our team?)

      *What could be the disadvantage?*
      tbd; I've been (and still I am) thinking about this question

              leapp-notifications leapp-notifications
              pstodulk@redhat.com Petr Stodulka
              leapp-notifications leapp-notifications
              RHEL Upgrades QE Team RHEL Upgrades QE Team
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: