openshift / cluster-resource-override-admission-operator Goto Github PK

This is my cr, note limitCPUToMemoryPercent isn't set ...

apiVersion: operator.autoscaling.openshift.io/v1
kind: ClusterResourceOverride
metadata:
    name: cluster
spec:
  podResourceOverride:
    spec:
      cpuRequestToLimitPercent: 5
      memoryRequestToLimitPercent: 5
      #limitCPUToMemoryPercent: 200

Example of get pod after deploying with the resource override operator enabled for this namespace ...

    Args:
      cp -rpf /tmp/Sample_data /tmp/sampledata;
    Limits:
      cpu:     0
      memory:  0
    Requests:
      cpu:        0
      memory:     0
    Environment:  <none>
    Mounts:
      /tmp/sampledata from sampledata-pv-volume (rw)

Events with namespace labeled ...

Warning  FailedCreate  20m    job-controller  Error creating: Pod "sample-data-job-bxxl9" is invalid: [spec.containers[0].resources.requests: Invalid value: "1m": must be less than or equal to cpu limit, spec.containers[0].resources.requests: Invalid value: "1Mi": must be less than or equal to memory limit]

... no issues deploying 1m/1Mi limits without the override operator in the middle.

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.12
• release-4.13

For more information, see the branching documentation.

ART team would like to request to prepare your operator to supply a 4.10 bundle (https://github.com/openshift/cluster-resource-override-admission-operator/tree/release-4.10/manifests) so that 4.10 operator publishing works. Thanks!

Now that we are fully branched for 4.5, please prepare your operator to supply a 4.5 bundle, so that 4.5 operator publishing works and doesn't overwrite 4.4 bundles. This means at least updating the package.yaml under https://github.com/openshift/cluster-resource-override-admission-operator/blob/master/manifests/clusterresourceoverride-operator.package.yaml

Reference: Get OLM operator owners to update their CSV channels

Hi,

We need urgent backposupport of CRO with forceSelinuxRelabel for Openshift 4.10 and 4.11 version.

Could you please help about this fix?

When I install the operator in openshift 4.11, there is no parameter for forceSelinuxRelabel.

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.17
• release-4.18

For more information, see the branching documentation.

when reset or update the ClusterResourceOverride

1. may request of the exist pods be auto reset?
2. may the pods be auto restart?

ART builds for operator are failing due to:

2020-01-20 12:02:37,547 ERROR [containers/clusterresourceoverride-operator] Unable to find openshift/ose-clusterresourceoverride-rhel7-operator in image-references data for clusterresourceoverride-operator

Your operator image references (e.g.

• clusterresourceoverride-rhel7-operator
• clusterresourceoverride-rhel7

This is causing ART image builds to fail since the names need to match what is in ocp-build-data (minus the openshift/ose- prefix):

• https://github.com/openshift/ocp-build-data/blob/46d3af428b4e67497a885aa31751482b0ad8a6d0/images/clusterresourceoverride-operator.yml#L22
• https://github.com/openshift/ocp-build-data/blob/46d3af428b4e67497a885aa31751482b0ad8a6d0/images/clusterresourceoverride.yml#L21

Now that we are fully branched for 4.7, please prepare your operator to supply a 4.7 bundle, so that 4.7 operator publishing works and doesn't overwrite 4.6 bundles. This means at least updating the package.yaml under
https://github.com/openshift/cluster-resource-override-admission-operator/tree/master/manifests

@jcantrill @richm

Reference: openshift-eng/ocp-build-data#708

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.6

Contact the Test Platform or Automated Release teams for more information.

Operator (4.8.0-202205121606) was deployed via OperatorHub with manual approval on OCPv.4.8.35
Simple ClusterResourceOverride with spec.podResourceOverride.spec.cpuRequestToLimitPercent = 25 was deployed.
Cluster was upgraded to v.4.9.43
Operator was upgraded to v.4.9.0-202208231335
Operator itself was upgraded however daemonset for CRO was not.
Operator logged the following error messages:
E0907 18:39:38.798875 1 worker.go:67] error syncing '/cluster': waiting for daemonset pods to be available name=clusterresourceoverride, requeuing

The issue was fixed by manually deleting daemonset and letting operator to recreate it.

I think daemonset recreation/update should be handled automatically by the operator

Until operator was upgraded and daemonset was recreated - all deployments (including scaling operations) were failing with the following error:
Error creating: Internal error occurred: failed calling webhook "clusterresourceoverrides.admission.autoscaling.openshift.io": failed to call webhook: an error on the server ("Internal Server Error: "/apis/[admission.autoscaling.openshift.io/v1/clusterresourceoverrides?timeout=5s](http://admission.autoscaling.openshift.io/v1/clusterresourceoverrides?timeout=5s%5C)": the server could not find the requested resource") has prevented the request from succeeding

The following branches are being fast-forwarded from the current development branch (master) as placeholders for future releases. No merging is allowed into these release branches until they are unfrozen for production release.

• release-4.7
• release-4.6

Contact the Test Platform or Automated Release teams for more information.

When running the e2e tests against OCP 4.12+ clusters the following warnings are being generated:

kubectl -n clusterresourceoverride-operator rollout status -w deployment/clusterresourceoverride-operator
deployment "clusterresourceoverride-operator" successfully rolled out
export GO111MODULE=on
GO111MODULE=on GOFLAGS=-mod=vendor go test -v -count=1 -timeout=15m ./test/e2e/... --kubeconfig=/ocp4-workdir/auth/kubeconfig --namespace=clusterresourceoverride-operator
=== RUN   TestDynamicClient
W0220 11:08:19.409509    6778 warnings.go:70] would violate PodSecurity "restricted:latest": seccompProfile (pod or container "test-dynamic-client" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
W0220 11:08:19.414411    6778 warnings.go:70] would violate PodSecurity "restricted:latest": seccompProfile (pod or container "test-dynamic-client" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
W0220 11:08:19.421444    6778 warnings.go:70] would violate PodSecurity "restricted:latest": seccompProfile (pod or container "test-dynamic-client" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
--- PASS: TestDynamicClient (0.05s)

This happens due to the pod definition in test/e2e/dynamic_test.go missing the required security settings.