global context proposal

[JimBugwadia]

No description provided.

[MariamFahmy98]

I can't find the resource cache proposal in the KDP.
Am I missing something?

[JimBugwadia]

I can't find the resource cache proposal in the KDP. Am I missing something?

Oops...forgot to add the file!

As they say, good design is invisible :-)

Added.

[chipzoller]

It seems like it may also be a good idea to register a new metric which indicates how many total cache informers exist at a given time to assist users (and maintainers) in troubleshooting.

[eddycharly]

Ooops, I missed that, will look at it next week !

[chipzoller]

What will happen if a resourceCache context variable is declared yet there are no corresponding resources in the cache? Does the context var fail to be evaluated, does it evaluate automatically to [], something else?

[MarcelMue]

Especially cache size would be very important. With this current proposal I see the risk of Kyverno Policies being created which have a large influence on overall cache size.

[vishal-chdhry]

Updating drawbacks of this approach

Suggested change

	API calls do not leverage caching by default.
	If needed, we can add a separate caching mechanism for API calls in the future.
	1. API calls do not leverage caching by default. If needed, we can add a separate caching mechanism for API calls in the future.
	2. Using `cache.kyverno.io/enabled: "true"` can cause issues when users forgets to add them to the resource.
	1. It is easy to miss a resource when adding the label. `apiCall` will return all the resources of the given type while `resourceCache` will return only those resources that have the label. In case of 1-10k resources.
	2. Users might not want to have a kyverno specific label in all their resources across all namespaces.
	3. For the usecase mentioned in [motivation](#motivation), we need to add resource to the cache when the policies is applied, otherwise, when the resource is applied for the first time, it will fail because of the timeout like it currently does. This will take away the abilities to have substitutions in `resourceCache` (e.g. `namespace: "{{request.namespace}}"`) and the `resourceCache` field will have to be static.

[realshuting]

Suggested change

	A `GlobalContextEntry` will can be either of the following types:
	A `GlobalContextEntry` can be either of the following types:

[chipzoller]

The two things I, as a user, really need answered here are:

1. what happens when I try and fetch something from global cache and it's empty?
2. what does the returned data look like when when the cache is populated? I want it to look the same as if I did a raw API call to the K8s API so I can avoid having to write separate JMESPath queries.

[realshuting]

The two things I, as a user, really need answered here are:

1. what happens when I try and fetch something from global cache and it's empty?
2. what does the returned data look like when when the cache is populated? I want it to look the same as if I did a raw API call to the K8s API so I can avoid having to write separate JMESPath queries.

cc @vishal-chdhry @KhaledEmaraDev

[vishal-chdhry]

1. In the original implementation, if the context entry is not present, the policy would have returned an error. Khaled can you verify that this is the current behaviour.

2. Unfortunately, there is a slight difference, when we do an API call and dont mention the resource, we get a list in return. But in the global context, we are using imformers and informer returns an array of object. Basically the output of global context is .Items of the corresponding apicall

[KhaledEmaraDev]

The two things I, as a user, really need answered here are:

1. what happens when I try and fetch something from global cache and it's empty?
2. what does the returned data look like when when the cache is populated? I want it to look the same as if I did a raw API call to the K8s API so I can avoid having to write separate JMESPath queries.

cc @vishal-chdhry @KhaledEmaraDev

1. Just like Vishal mentioned. Plus, it would set the policy to NotReady and with the correct reason of the Cache Entry not existing.

2. Again Vishal is correct here. APICall would return a DeploymentList array each of which would have its own items. So it has to be queried the old way for instance [0].items | length(@) while the resource would return items to begin with.

We could edit the response of the APICall. But it would be hacky as sometimes it will be a list sometimes not. Depending on the query.