Base Platform and Agents

[NeilHanlon]

Kube and non-kube builders to be targeted

Need to support multiple architectures for building.

All code should be unit tested.

Need to begin with mapping out what peridot does currently

[nazunalika]

As an addendum, it may be wise to be able to set this up in a non-kube environment entirely. Meaning, kube should not be an absolute requirement (think like koji and CentOS' reimzul). I can see this providing these possibilities:

• This could make it possible to create ansible roles or even collections that can install peridot that don't need to interact with kube environments
• Make it easier to develop and hack on the base platform in general without needing to install kube locally

[nazunalika]

Something I was thinking about too when it comes to modules. This may be something that also needs to be incorporated into srpmproc in a way. I was thinking that instead of relaying specifically on commit hashes for the "ref" portion of each module component, why not just rely on the branch name?

Traditionally, MBS can take either a commit hash that it will conveniently look up or just the branch name. Regardless of which method, MBS stores this information into the database and does a comparison the next time a new build is requested. If you just use a branch name, it checks the latest commit on the repo to the commit hash it last used. If there's a match, it won't bother rebuilding. As far as I can tell in v1, building a module rebuilds everything, which can be time consuming depending on the size of it (like maven, for example).

And importing a module should only refresh the yaml (in case upstream or otherwise made some sort of change), and just leave the "ref" as the branch name that we're using e.g. rX-stream-version. Ideally it could work like this:

• RPM's imported if necessary
• Module imported
  • Each component "ref" value will be a branch name rX-stream-version that matches upstream
• Module build requested
• Checks each component hash in git and compares them to database
  • If match and previous build succeeded, reuse component
  • If no match...
    • Mark for build
    • If build with that hash was successful, import hash into database and mark as successful
• If entire module build succeeds, all components for the module with its corresponding git hashes should be marked as successful, including hash of the module repo, to prevent accidental rebuild of an entire module.