Restart deployment/daemonset when referred resources' content is changing

[chenliu1993]

Hi team, I met a senario when using kapp's versioned annotation. Opened this issue to track the question.
The scenario is:
config C refers a secret S in its data, and this config C is referred by a Deployment D. Will update the content of secret S trigger restart of Deployment D?

I get a solution that is referring the secret S directly in Depoyment D. But I think that may be not the best way.

Will kapp's versioned annotation supports above scenario? Or already supported?
Thanks.

[cppforlife]

config C refers a secret S in its data, and this config C is referred by a Deployment D. Will update the content of secret S trigger restart of Deployment D?

it will not today, since kapp does not support updating resource references within arbitrary content (data of ConfigMap). im not sure we want to extend kapp to try to update contents of ConfigMaps with new resource name. (we do something like this in kbld to update image refs but it only works for json/yaml content).

I get a solution that is referring the secret S directly in Depoyment D. But I think that may be not the best way.

currently, that's the only way to make this work with versioned resources. note that referencing a secret on the deployment does not mean that you Deployment needs to actually consume it directly, it could still be doing it through changed ConfigMap.

outside of versioned resources feature, you could do what folks do with templating tricks to hash content and throw in an annotation onto Deployment, but to me that feels more work that referencing secret on the Deployment.

as an enhancement to versioned resources feature, i could imagine supporting special annotation that will make kapp consider ConfigMap as related to changed Secret which then would trigger Deployment change. e.g.

kind: Secret
metadata:
  name: something
  annotations:
   kapp.k14s.io/versioned: ""
# ...
---
kind: ConfigMap
metadata:
  name: config
  annotations:
   kapp.k14s.io/versioned: ""
   kapp.k14s.io/versioned-explicit-ref: "v1/Secret/something" <--- this would be "synthetic reference"
# ...
---
kind: Deployment # only references ConfigMap
# ...

[chenliu1993]

Thanks @cppforlife . The information is really detailed😊 and I would vote for the example solution kapp.k14s.io/versioned-explicit-ref if it is doable.

[renuy]

Moving it to carvel accepted. Will try and prioritise this

[renuy]

Pulling this issue for the next release v0.41.0 . @100mik , please update the approach here.

[100mik]

We can support a synthetic reference which mirrors the latest versioned name of a versioned resource.

For example, a synthetic reference like

kapp.k14s.io/versioned-explicit-ref: default/v1/Secret/credentials

will be assigned the following value on deployment

kapp.k14s.io/versioned-explicit-ref: credentials-ver-1

This leads to the referencing versioned resource being versioned whenever the referenced resource is. It can be used to explicitly refer a versioned resource from a non-versioned resource as well.

Ongoing work on this with this draft PR!

[100mik]

Addressing the questions raised in the ongoing PR, we will allow users to reference a single or multiple resources in a JSON object with specified format.

kapp.k14s.io/versioned-explicit-ref: '{ "references": [ { "namespace": <resource-namespace>, "apiGroup":  <resource-apiGroup>, "kind" : <resource-kind>, "name":  <resource-name> } ] }'

• references can have multiple objects referring to different resources
• The namespace key should be omitted for cluster scoped resources

@chenliu1993 I believe this will satisfy your requirements ?