-
Notifications
You must be signed in to change notification settings - Fork 172
Update hncconfig webhook to handle object overwriting and refactor forest sourceObjects
field
#1106
Conversation
/retest |
/assign @adrianludwin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my review for the first commit only. Overall I really like it; I've left some comments that could simplify it even further (and possibly identifies one bug).
328f268
to
1595f36
Compare
/retest |
1595f36
to
4515ec9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments for the first commit - will come back and finish in a bit (just need to take a break)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I'm now fully finished with the first commit :) On to the second commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Second commit lgtm apart from some relatively minor suggestions
Refactor the `forest.namespace.sourceObjects` field to not only store source objects with `Propagate` mode, but all the source objects as long as there once is an object reconciler created for the type. This changed field will provide data for handling source object name conflicts even for types changing mode from others to `Propagate`. In addition, since we will implement HNC exceptions soon, we will not simply rely on whether a source object exists in this field, but will get all the info on the fly from the instance itself to decide whether to propagate or enqueue objects. Update object reonciler dependencies on the old `originalObjects` field with only source objects with `Propagate` mode. Check if the object `shouldPropagate()` on the fly. Remove the check of whether the source object is updated to ensure a mode change from `Remove` to `Propagate` still enqueues an unchanged source's descendants for them to be created. Note this will increase the number of enqueued objects but it should be fine since we only write if there's a diff and read is fast from cache. Update object reconciler to still not deleting a descendant object with the same name as in an ancestor for types with 'Remove' mode. Add a test case for that. The test failed before and passed after the change. Consider there's an object overwriting conflict only if the conflicting source in the ancestor can propagate, e.g. with no finalizers. Add a new test case. Tested by `make test`.
Add new hncconfig webhook rules and new test cases. Check if changing type mode(s) to `Propagate` would cause overwriting source by looking up the `objectNames` data. Deny the request and output all the conflicts of one type change if it would cause overwriting. Tested by "make test" and manually on a GKE cluster with multiple objects with the same name in the same tree or different trees. The webhook message would look like this: Cannot update configuration because setting type "/v1, Kind=Secret" to 'Propagate' mode would overwrite user-created object(s): Object "my-creds2" in namespace "acme-org" would overwrite the one in "team-a" Object "my-creds2" in namespace "acme-org" would overwrite the one in "team-b" Object "my-creds" in namespace "bcme-org" would overwrite the one in "team-c" Object "my-creds2" in namespace "bcme-org" would overwrite the one in "team-c" To fix this, please rename or remove the conflicting objects first.
4515ec9
to
0b355cb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
/hold
/assign @rjbez17
Hey Ryan, this is a big PR with two commits. I'd recommend reviewing them individually:
- Commit # 1 is about always saving all source objects in the forest, even if we're not propagating objects. This enables...
- Commit # 2 which checks the forest for objects that are about to be overwritten if we change the mode to Propagate.
Note that # 2 will only have an effect if the reconciler is currently not in the Ignore mode for that type of object - which it typically will be. A future change will guide users to first change to the Remove mode, and only later change to the Propagate mode.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adrianludwin, yiqigao217 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 |
Update: Passed all e2e tests. Initially I got:
1 & 2 passed when I ran it manually. 3 passed by itself if it's a stand-alone test (with The 1st demo failure also failed on master. I suspect there's a bug in the test that it should use /assign @adrianludwin |
Yes, @GinnyJI is looking into the e2e test failures on |
/lgtm |
Update forest field
sourceObjects
to store all the names of user-createdobjects by GVK as long as there's an object reconciler for that GVK.
Change object reonciler behaviors dependent on the previous forest field
originalObjects
, which only stores source objects for 'Propagate' types.Add test cases for corner cases.
Add new hncconfig webhook rules and new test cases. Check if changing
type mode(s) to
Propagate
would cause overwriting source by lookingup the
objectNames
data. Deny the request and output all the conflictsif it would cause overwriting.
Tested by "make test" and manually on a GKE cluster with multiple
objects with the same name in the same tree or different trees. Passed
all e2e tests too.
The webhook message would look like this:
Part of #1102, #1076