Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix daemon-set-controller bootstrap RBAC policy #62146
What this PR does / why we need it:
Which issue(s) this PR fixes :
Special notes for your reviewer:
referenced this pull request
Apr 10, 2018
The unit test doesn't demonstrate that the permission is sufficient, it just records the fact that the permission was added to the role.
This type of externally visible behavior seems like an ideal candidate for the e2e suite (and possibly even a conformance test, to ensure that in a conformant cluster, the daemonset controller handles this case)
@liggit I don't think we should add ControllerRevision collision as an e2e test suite. The RBAC permissions associated with the DaemonSet controller are an implementation detail of the controller. The behavior with respect to the resolution of collisions for controller revisions is not visible to end users. With respect to conformance, I don't think its fair to say that a Kubenetes cluster that does not have RBAC configured to allow its DaemonSet controller to perform a get against ControllerHistory is not a valid Kubernetes cluster.
the net effect of the bug was definitely end-user visible (create/delete a few times hung the controller). That's a test gap I would want to ensure was covered in a actual cluster to flush out unexpected interactions (e.g. create, delete, create, delete, create, and ensure the expected pods materialize)
Phrasing it more in black box terms rather than trying to drive a hash collision makes sense to me. I think we'd want the scenario that broke to actually be tested, but if you want to merge this without addressing the test gap, I won't block on it.
[APPROVALNOTIFIER] This PR is APPROVED
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing
I was not able to reproduce this by creating and deleting DaemonSets, and it's not clear to me how to reproduce it. Hash collision (i.e. ControllerRevision name collision) is different from what we saw in #62145, although it can trigger the same permission error. An e2e test for hash collision handling would have failed without this RBAC permission (it's more suitable to be an integration test, but integration test doesn't check RBAC), but it doesn't really cover the scenario described in this bug.
OTOH this PR adds a missing RBAC permission that DaemonSet controller clearly needs.