each adoption handler only sees its own secret

[steven-rand]

Description

Intended to fix #409. Limits each secret adoption handler to managing its own secret, and prevents each one from discarding another secret managed by the operator as extra.

Testing

Added unit test which failed prior to the change and succeeds after.

References

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[steven-rand]

I have read the CLA Document and I hereby sign the CLA

[steven-rand]

Hi @ecordell @alecmerdler, I was wondering whether either of you would be the right person to review this change since I saw that you worked on #403. Happy to provide any context if that's useful, although hopefully the write-up in #409 describes the behavior we're seeing

[alecmerdler]

@steven-rand Thanks for your contribution! We'll try and take a look at this as soon as possible.

[steven-rand]

Hi @alecmerdler, I was wondering whether you've had a chance to take a look here? I'm not married to this particular solution; more just interested in finding some solution to the problem described in #409

[ecordell]

Hi @steven-rand - thanks for your patience here, took a while to get to this

The approach in this PR is okay but not ideal - it means that if other processes created objects with duplicate labels (say you accidentally deploy two spicedb-operators at the same time, or do a backup/restore of objects), the operator won't necessarily identify the right one to remove.

I made #417 as an attempt to solve this in a way that lines up with the existing adoption handler behavior - each role a secret can have is tracked with a separate field manager / label / index, so each adoption handler then works "normally".

[steven-rand]

Thanks @ecordell, I'll close this PR out in favor of yours, which I see just merged. Do you have a sense for when your change will make it into a release? We'd be interested in getting this change deployed to our environments as soon as that's possible