Overview

Anarchy Runner is logging permission denied events when attempting to access Poolboy ResourceClaims and ResourceHandles.

I had (possibly incorrectly) assumed this might have been part of the Poolboy to Anarchy integration which is enabled with the following helm chart values when deploying Poolboy.

anarchy:
  create: true

Example errors

# Example read of ResourceHandle
lodestar-babylon-operators/anarchy-runner-default-hfpvf[runner]: fatal: [localhost]: FAILED! => {"changed": false, "error": 403, "msg": "Failed to retrieve requested object: b'{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"resourcehandles.poolboy.gpte.redhat.com \\\\\"guid-wxd2j\\\\\" is forbidden: User \\\\\"system:serviceaccount:lodestar-babylon-operators:anarchy-runner-default\\\\\" cannot get resource \\\\\"resourcehandles\\\\\" in API group \\\\\"poolboy.gpte.redhat.com\\\\\" in the namespace \\\\\"lodestar-babylon-operators\\\\\"\",\"reason\":\"Forbidden\",\"details\":{\"name\":\"guid-wxd2j\",\"group\":\"poolboy.gpte.redhat.com\",\"kind\":\"resourcehandles\"},\"code\":403}\\n'", "reason": "Forbidden", "status": 403}

# Example delete of ResourceClaim
lodestar-babylon-operators/anarchy-runner-default-hfpvf[runner]: ...ignoring
lodestar-babylon-operators/anarchy-runner-default-hfpvf[runner]:
lodestar-babylon-operators/anarchy-runner-default-hfpvf[runner]: TASK [babylon_anarchy_governor : Delete resource claim] ************************
lodestar-babylon-operators/anarchy-runner-default-hfpvf[runner]: fatal: [localhost]: FAILED! => {"changed": false, "error": 403, "msg": "Failed to retrieve requested object: b'{\"kind\":\"Status\",\"apiVersion\":\"v1\",\"metadata\":{},\"status\":\"Failure\",\"message\":\"resourceclaims.poolboy.gpte.redhat.com \\\\\"do500.day2.idm-22155\\\\\" is forbidden: User \\\\\"system:serviceaccount:lodestar-babylon-operators:anarchy-runner-default\\\\\" cannot get resource \\\\\"resourceclaims\\\\\" in API group \\\\\"poolboy.gpte.redhat.com\\\\\" in the namespace \\\\\"lodestar-babylon-operators\\\\\"\",\"reason\":\"Forbidden\",\"details\":{\"name\":\"do500.day2.idm-22155\",\"group\":\"poolboy.gpte.redhat.com\",\"kind\":\"resourceclaims\"},\"code\":403}\\n'", "reason": "Forbidden", "status": 403}

Versions

The current versions of the Babylon Operators are being used in this test.

• Babylon Operators v0.11.5
• AgnosticV Operator v0.15.4
• AgnosticD v1.0.9
• Anarchy v0.16.25
• Anarchy Governor v0.9.3
• Poolboy v0.10.8

Questions

• Am I missing these permissions already being deployed from another Helm chart and a fix is not required?

• What is the minimum verbs Anarchy Runner requires for the Runner to access Poolboy CRDs to function? (Currently I have granted all in tests)

• Is there an existing Group which contains all Runner service accounts that can be used in place of anarchy-runner-default in case additional runners are used in future?

PR

Please see PR #63 for the current status of testing a fix.

Hi there,

While testing out Poolboy I noticed the default value for the Helm chart is to enable poolboy admin.

However it seems the image isn't available publicly at quay.io/redhat-cop/poolboy-admin

Has the image been moved to a new path?

Thanks

The config setup when running containerized in kubernetes would be much simpler with load_incluster_config.

Currently just checks kind == "Status" for non-resource events, but this isn't enough because a resource kind could be "Status"

The unique id, "guid", is considered the generated portion of the ResourceHandle name. Currently poolboy expects that the generated portion is always five characters long.

Poolboy should use metadata.generateName to determine the unique suffix rather than have a length of five characters hard-coded.

At this moment there is not a suitable python operator module available.

The project which shows the most promise is kopf:

https://github.com/zalando-incubator/kopf/

In order to leverage kopf we would like to be able to limit the operator to watch a specific namespace and to watch custom resources for which it does not have write access.

zalando-incubator/kopf#157
zalando-incubator/kopf#158

python-openapi/openapi-core#154

Custom validation checks should process using jinja2 to validate check conditions:

spec:
  validation:
    customValidation:
    - name: destroy schedule must be no more than 14 days from creation
      check: spec.actionSchedule.destroy < timestamp(resource_claim.metadata.creationTimestamp).add('14d')
    - name: stop schedule must be no more than 8 hours from now
      check: spec.actionSchedule.stop < timestamp.utcnow.add('8h')

There are some edge cases where the kind field is not unique, templates and processedtemplates in openshift.

Test suite needed to verify operator functionality.

There is a possibility that a handle may be created for a claim but the claim is not updated to indicate that the claim has been fulfilled

To accelerate development process.

Test suite should also be adapted so it can be run with local operator run.

In util.py only dictionaries are currently handled. Resource lists are currently not handled.

The python jsonpatch module calculates diffs can produce move operations while the poolboy design expects only add, remove, and replace to be used when processing allowed update filters.

Poolboy should stop using the jsonpatch module in favor of calculating json patches directly so that we can be sure the patches match expectations.

When a ResourceClaim is updated the new definition should be re-checked for validity and errors should be reported.

There are currently annotations on created resources, but not labels. The values that are annotations that should likely be labels are:

      poolboy.gpte.redhat.com/resource-claim-name: ...
      poolboy.gpte.redhat.com/resource-claim-namespace: ...
      poolboy.gpte.redhat.com/resource-handle-name: ...
      poolboy.gpte.redhat.com/resource-handle-namespace: ...
      poolboy.gpte.redhat.com/resource-provider-name: ...
      poolboy.gpte.redhat.com/resource-provider-namespace: ...

We would need to continue to set both labels and annotations for several releases when the labels are added.