Update Sidecar Scopes

[sschepens]

Please provide a description of this PR:
With Issue #41453 it was raised that currently Istio rebuilds it's internal indexes whenever any configuration changes.

This is a starting PR to start processing Sidecar updates in a more efficient manner.
Whenever only sidecar resources are updated, we can safely only process changed sidecars, using the old index but:

• deleting sidecar scopes which were deleted
• regenerating sidecar scopes which were updated
• creating sidecar scopes which were created

breaking changes:

• sidecar ordering: currently sidecars were ordered by creation date, this allowed that if multiple sidecars matched a workload, the sidecar that was actually selected was predictable (oldest sidecar). I'm guessing this shouldn't actually be a problem because it's not something anyone should be doing and the behavior is actually contrary to what documentation specifies. The behavior of the system is undefined if more than one selector-less Sidecar configurations exist in a given namespace. The behavior of the system is undefined if two or more Sidecar configurations with a workloadSelector select the same workload instance.

questions:

• I'm actually reusing and modifying the previous sidecarIndex, could this actually be a problem? 🤔 Copying the maps would probably be too costly in the long run, but maybe we need to use sync.Map.
• I'm detecting resource deletions whenever we get a nil response from store.Get, I really don't know if this is correct or if there would be a better way of knowing this.

@howardjohn @hzxuzhonghu @ramaraochavali since you were involved in the issue.

I'm sending this as a draft to see if the approach is correct and have some feedback.

My intentions would be to continue expanding this way of efficient processing of updates into all resources eventually, one at a time.

[istio-testing]

Hi @sschepens. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hzxuzhonghu]

/ok-to-test

[hzxuzhonghu]

@sschepens I think you can apply to be istio member, the it will no need manually label ok-to-test

[hzxuzhonghu]

I think the most common scenario is service/vs, etc updates, not sidecar itself. So I wonder can we only do delta update sidecarScope with the granularity of resource type.

[sschepens]

@sschepens I think you can apply to be istio member, the it will no need manually label ok-to-test

Sure, would love, is there any documentation on the process?

I think the most common scenario is service/vs, etc updates, not sidecar itself. So I wonder can we only do delta update sidecarScope with the granularity of resource type.

Yes I know this is the case, I just want to start making incremental changes, after this PR, I will add only to update Sidecars which had services/vs/drs changed, and then some other more changes. Breaking this up makes it easier to review.

[hzxuzhonghu]

@sschepens FYI https://github.com/istio/community/blob/master/ROLES.md#member

[sschepens]

@sschepens FYI https://github.com/istio/community/blob/master/ROLES.md#member

thanks @hzxuzhonghu created a PR for adding myself as member istio/community#856

[sschepens]

@howardjohn would really like your feedback here

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2022-10-29. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.