Learn more about these different git repos.
Other Git URLs
OK - In order to get the "demo" ready for Flock, we released some unmerged patches that we're not quite happy with:
relevance_key
relevance_value
So - let's figure how how we want to solve these two things. Here, let's take the second of the two.
We essentially just want a whitelist of packages here - but that whitelist is going to grow unbounded as the the Fedora Atomic CI Pipeline tries to conquer the world. On the admin side, I don't want us to be responsible for maintaining that list. We won't scale.
Proposal, we add a new subclass of Rule called RemoteRule that can use the value of the subject to construct a URL where it will check for an extension to the policy, specific to that subject.
Rule
RemoteRule
subject
This will let us define greenwave.yaml files in the dist-git repos of packages that should be gated on Fedora Atomic CI results. Packagers become responsible for defining extensions to the policy for their specific packages. greenwave will first do a requests.head to see if the file exists, and, if it does it will pull it down, load it, and use it to additionally evaluate the subject of the decision.
greenwave.yaml
requests.head
Note - we have to be careful here, because loading remote untrusted yaml will introduce an attack vector. @puiterwijk should be cc'd on the PR.
See also #74 for the bit about the relevance_key.
/cc @pingou, @bowlofeggs, @mjia, @dcallagh, @puiterwijk.
I was at first not convinced but it has grown on me and I think I start to like this approach more.
It gives us the possibility to put tests in dist-git, have them run as part of the Fedora Atomic CI pipeline without gating on them. It gives time to the maintainer to test the tests, see how they behave on the pipeline, tweak them, without actually impacting their workflow. Then once things are ready, they can turn the gating on.
In addition, it gives us the possibility to put tests in dist-git from today and only turn the gating on once it has been activated in bodhi.
So yeah, I think I like this approach more and more :)
So this issue is essentially just asking for per-package policies, right?
The two options we have are:
Allow Greenwave policies to specify a list of package names which the policy applies to. Opting your package in or out of the policy thus requires a PR against the Fedora Greenwave configuration.
Have Greenwave check each package's dist-git to look for extra package-specific policies to apply, when making a decision. Opting your package in or out of the policy thus requires committing to that package's dist-git.
I guess the downsides of option 1 is that the Greenwave application config is buried deep inside Fedora infra ansible right now. Even if we moved it out to some separate git repo, it would still be part of Greenwave's configuration, so the PRs would need to be reviewed and merged by the infra team. And changing it during release freeze would theoretically require a freeze break.
Option 2 avoids those problems and lets packagers directly control the per-package policy without bothering infra. The major downside is that now Greenwave is making a lot more HTTP requests. And Greenwave will also depend on dist-git (well Pagure specifically?) to be up and serving requests in order to make its decision. And we would probably need to be even more careful and defensive about parsing the policies, because you wouldn't want a mistake in some package's policy interfering with everything else in Greenwave. Because you know, there would be no freeze in this case. :-)
Another consideration is: overall which direction do we want to take, in terms of where package configuration lives? For example we recently had one centralised place to manage everything (PkgDB), and have started heading in a more decentralised direction. Nowadays, you go to Koschei itself to opt your package in/out of scratch rebuilds. You go to a separate, but centralised, git repo (fedora-scm-requests) to opt in/out of upstream release monitoring. You commit your tests directly to your package's dist-git repo.
So we are not very consistent today. But do we want to move configuration for each tool into the tool itself (like Koschei)? In that case option 1 makes sense. Or do we want to move towards everything managed through the dist-git repo of the package itself? In that case, option 2 makes sense.
It seems like dist-git is the new center of gravity these days (container.yml for OSBS, tests/ for the atomic ci pipeline, etc..). Let's follow suit.
container.yml
tests/
Metadata Update from @gnaponie: - Issue assigned to gnaponie
One potential problem, if we are using dist-git to configure this: which branch do we look at? If it's a Bodhi update for F26, we would want to apply the policy from each package in the update from the f26 branch in dist-git. Not master unconditionally. Right?
Also, just mapping from the various item types back to a specific dist git repo for the packages in question, might be kind of tricky... #126 may help here?
PR: https://pagure.io/greenwave/pull-request/162
Metadata Update from @lholecek: - Issue close_status updated to: Fixed - Issue set to the milestone: 0.7 - Issue status updated to: Closed (was: Open) - Issue tagged with: feature
Login to comment on this ticket.