Skip to content

Commit

Permalink
[release-payload-controller] Adding missing RBAC (#37910)
Browse files Browse the repository at this point in the history
  • Loading branch information
bradmwilliams authored Mar 30, 2023
1 parent 6778d51 commit 18a2a9b
Show file tree
Hide file tree
Showing 3 changed files with 74 additions and 55 deletions.
116 changes: 61 additions & 55 deletions clusters/app.ci/release-controller/admin_01_releasepayload_crd.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.7.0
controller-gen.kubebuilder.io/version: (devel)
creationTimestamp: null
name: releasepayloads.release.openshift.io
spec:
Expand All @@ -25,32 +25,31 @@ spec:
is a definition of how releases are calculated. When a ReleasePayload is
generated, it will be generated in the same namespace as the imagstream
that produced it. If/when an update occurs, to one of these imagestreams,
the release-controller will: 1. Create a point-in-time mirror of the updated
imagestream 2. Create a new Release from the mirror - Any errors before
this point will cause the release to marked `Failed` 3. Launches a set
of release analysis jobs 4. Launches an aggregation job 5. Launches a
set of release verification jobs - These can either be `Blocking Jobs`
which will prevent release acceptance or `Informing Jobs` which will not
prevent release acceptance. 6. For Stable releases, launches a set of jobs
to test a subset of the supported upgrades defined inside the release image
itself. While these jobs do not have any real bearing on the acceptance
or rejection of a ReleasePayload, they will be monitored and their respective
results captured. The hope would be to use these results to provide
a convenient way to override a \"Rejected\" release caused by a blocking
upgrade job. 7. Monitors for job completions - If all `Blocking Jobs`
complete successfully, then the release is `Accepted`. If any `Blocking
Jobs` fail, the release will be marked `Rejected` 8. Publishes all
results to the respective webpage \n Example: ART: 1. Publishes an update
to the `ocp/4.9-art-latest` imagestream \n Release-controller: 1. Creates
a mirror named: `ocp/4.9-art-latest-2021-09-27-105859` 2. Creates a ReleasePayload:
`ocp/4.9.0-0.nightly-2021-09-27-105859` -Labels: release.openshift.io/imagestream=release
\ release.openshift.io/imagestreamtag-name=4.9.0-0.nightly-2021-09-27-105859
\ 3. Creates an OpenShift Release: `ocp/release:4.9.0-0.nightly-2021-09-27-105859`
\ 4. Update ReleasePayload conditions with results of release creation job
\ If the release was created successfully, the release-controller: 5.
Launches: 4.9.0-0.nightly-2021-09-27-105859-aggregated-<name>-analysis-<count>
\ 6. Launches: 4.9.0-0.nightly-2021-09-27-105859-aggregated-<name>-aggregator
\ 7. Launches: 4.9.0-0.nightly-2021-09-27-105859-<name> \n When ART promotes
the release-controller will: 1. Create a point-in-time mirror of the updated
imagestream 2. Create a new Release from the mirror - Any errors before
this point will cause the release to marked `Failed` 3. Launches a set of
release analysis jobs 4. Launches an aggregation job 5. Launches a set of
release verification jobs - These can either be `Blocking Jobs` which will
prevent release acceptance or `Informing Jobs` which will not prevent release
acceptance. 6. For Stable releases, launches a set of jobs to test a subset
of the supported upgrades defined inside the release image itself. While
these jobs do not have any real bearing on the acceptance or rejection of
a ReleasePayload, they will be monitored and their respective results captured.
\ The hope would be to use these results to provide a convenient way to
override a \"Rejected\" release caused by a blocking upgrade job. 7. Monitors
for job completions - If all `Blocking Jobs` complete successfully, then
the release is `Accepted`. If any `Blocking Jobs` fail, the release will
be marked `Rejected` 8. Publishes all results to the respective webpage
\n Example: ART: 1. Publishes an update to the `ocp/4.9-art-latest` imagestream
\n Release-controller: 1. Creates a mirror named: `ocp/4.9-art-latest-2021-09-27-105859`
2. Creates a ReleasePayload: `ocp/4.9.0-0.nightly-2021-09-27-105859` -Labels:
release.openshift.io/imagestream=release release.openshift.io/imagestreamtag-name=4.9.0-0.nightly-2021-09-27-105859
3. Creates an OpenShift Release: `ocp/release:4.9.0-0.nightly-2021-09-27-105859`
4. Update ReleasePayload conditions with results of release creation job
If the release was created successfully, the release-controller: 5. Launches:
4.9.0-0.nightly-2021-09-27-105859-aggregated-<name>-analysis-<count> 6.
Launches: 4.9.0-0.nightly-2021-09-27-105859-aggregated-<name>-aggregator
7. Launches: 4.9.0-0.nightly-2021-09-27-105859-<name> \n When ART promotes
a GA release, they will assemble releases themselves, publish it to quay.io,
and then update the \"stable\" release stream (i.e. ocp/release) with the
corresponding payload. In this scenario, the release-controller will perform
Expand All @@ -74,22 +73,22 @@ spec:
\n Mapping from a Release to ReleasePayload: A ReleasePayload will always
be named after the Release that it corresponds to, with the addition of
a random string suffix. Both objects will reside in the same namespace.
\n \tFor a release: `ocp/release:4.9.0-0.nightly-2021-09-27-105859` \tA
corresponding ReleasePayload will exist: `ocp/4.9.0-0.nightly-2021-09-27-105859`
\n Mapping from ReleasePayload to Release: A ReleasePayload is decorated
with a couple labels that will point back to the Release that it corresponds
to: - release.openshift.io/imagestream=release - release.openshift.io/imagestreamtag-name=4.9.0-0.nightly-2021-09-27-105859
\n For a release: `ocp/release:4.9.0-0.nightly-2021-09-27-105859` A corresponding
ReleasePayload will exist: `ocp/4.9.0-0.nightly-2021-09-27-105859` \n Mapping
from ReleasePayload to Release: A ReleasePayload is decorated with a couple
labels that will point back to the Release that it corresponds to: - release.openshift.io/imagestream=release
- release.openshift.io/imagestreamtag-name=4.9.0-0.nightly-2021-09-27-105859
\n Because the ReleasePayload and the Release will both reside in the same
namespace, the release that created the ReleasePayload will be located here:
\n \t<namespace>/<release.openshift.io/imagestream>:<release.openshift.io/imagestreamtag-name>
\n <namespace>/<release.openshift.io/imagestream>:<release.openshift.io/imagestreamtag-name>
\n Similarly, the ReleasePayload object itself also has the PayloadCoordinates
(.spec.payloadCoordinates) that point back to the Release as well: \n \tspec:
\t payloadCoordinates: \t imagestreamName: release \t imagestreamTagName:
4.9.0-0.nightly-2021-09-27-105859 \t namespace: ocp \n The release that
created the ReleasePayload will be located here: \n \t<namespace>/<imagestreamName>:<imagestreamTagName>
\n Compatibility level 4: No compatibility is provided, the API can change
at any point for any reason. These capabilities should not be used by applications
needing long term support."
(.spec.payloadCoordinates) that point back to the Release as well: \n spec:
payloadCoordinates: imagestreamName: release imagestreamTagName: 4.9.0-0.nightly-2021-09-27-105859
namespace: ocp \n The release that created the ReleasePayload will be located
here: \n <namespace>/<imagestreamName>:<imagestreamTagName> \n Compatibility
level 4: No compatibility is provided, the API can change at any point for
any reason. These capabilities should not be used by applications needing
long term support."
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
Expand All @@ -112,9 +111,9 @@ spec:
properties:
imagestreamName:
description: 'ImagestreamName is the location of the configured
"release" imagestream - This is a configurable parameter ("to")
"release" imagestream - This is a configurable parameter ("to")
passed into the release-controller via the ReleaseConfig''s
defined here: https://github.com/openshift/release/blob/master/core-services/release-controller/_releases'
defined here: https://github.com/openshift/release/blob/master/core-services/release-controller/_releases'
type: string
imagestreamTagName:
description: ImagestreamTagName is the name of the actual release
Expand Down Expand Up @@ -225,6 +224,17 @@ spec:
type: integer
type: object
type: array
payloadVerificationDataSource:
default: BuildFarmLookup
description: PayloadVerificationDataSource where JobRunResult
will be collected from.
enum:
- BuildFarmLookup
- ImageStreamTagAnnotation
type: string
x-kubernetes-validations:
- message: PayloadVerificationDataSource is immutable
rule: self == oldSelf
upgradeJobs:
description: UpgradeJobs are automatically generated jobs used
to execute upgrade tests against a ReleasePayload
Expand Down Expand Up @@ -255,6 +265,9 @@ spec:
type: object
type: array
type: object
x-kubernetes-validations:
- message: PayloadVerificationDataSource is required once set
rule: '!has(oldSelf.payloadVerificationDataSource) || has(self.payloadVerificationDataSource)'
type: object
status:
description: Status is the current status of the ReleasePayload
Expand Down Expand Up @@ -343,13 +356,12 @@ spec:
description: "Condition contains details for one aspect of the current
state of this API Resource. --- This struct is intended for direct
use as an array at the field path .status.conditions. For example,
type FooStatus struct{ // Represents the observations of a
foo's current state. // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type
\ // +patchStrategy=merge // +listType=map // +listMapKey=type
\ Conditions []metav1.Condition `json:\"conditions,omitempty\"
patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`
\n // other fields }"
type FooStatus struct{ // Represents the observations of a foo's
current state. // Known .status.conditions.type are: \"Available\",
\"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge
// +listType=map // +listMapKey=type Conditions []metav1.Condition
`json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\"
protobuf:\"bytes,1,rep,name=conditions\"` \n // other fields }"
properties:
lastTransitionTime:
description: lastTransitionTime is the last time the condition
Expand Down Expand Up @@ -591,9 +603,3 @@ spec:
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
8 changes: 8 additions & 0 deletions clusters/app.ci/release-payload-controller/admin_rbac.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,14 @@ rules:
- get
- list
- watch
- apiGroups:
- image.openshift.io
resources:
- imagestreams
verbs:
- get
- list
- watch
- apiGroups:
- prow.k8s.io
resources:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -38,6 +38,11 @@ def _cluster_scoped_rbac_resources(gendoc):
'resources': ['infrastructures'],
'verbs': ['get', 'list', 'watch']
},
{
'apiGroups': ['image.openshift.io'],
'resources': ['imagestreams'],
'verbs': ['get', 'list', 'watch']
},
{
'apiGroups': ['prow.k8s.io'],
'resources': ['prowjobs'],
Expand Down

0 comments on commit 18a2a9b

Please sign in to comment.