kapp deploy triggers a new versioned asset based on a predetermined interval

[voor]

trafficstars

Describe the problem/challenge you have We currently use kapp versioning capability for several Custom Resources beyond just ConfigMap and Secrets, this is very easily done with templateRules and allows for some super powerful capabilities like greatly reducing the complexity of how we roll out new AMIs with Cluster API.

One of the things the Cluster API AWS team is looking to do specifically in Cluster API is turn on some more deterministic lookups of AMIs, which would help us with no longer needing to populate the AMI ID field at all in our AWSMachineTemplate (see example here that means effectively this file never mutates anymore, but we still want it to mutate periodically to invoke a roll-out of the machines.

Describe the solution you'd like If there was some kapp annotation that looked like a cron job or had a similar behavior, like:

#@overlay/match by=overlay.subset({"kind":"AWSMachineTemplate"}),expects="0+"
---
metadata:
  #@overlay/match missing_ok=True
  annotations:
    kapp.k14s.io/versioned-cron-schedule: "0 0 * * 0"
    kapp.k14s.io/versioned: ""
    kapp.k14s.io/num-versions: "10"

with a result something like this (note the kapp.k14s.io/versioned-cron-schedule-last-run):

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha3
kind: AWSMachineTemplate
metadata:
  annotations:
    kapp.k14s.io/delete-strategy: orphan
    kapp.k14s.io/identity: ...
    kapp.k14s.io/num-versions: "10"
    kapp.k14s.io/original: '...'
    kapp.k14s.io/original-diff-md5: 58e0494c51d30eb3494f7c9198986bb9
    kapp.k14s.io/versioned: ""
    kapp.k14s.io/versioned-cron-schedule: "0 0 * * 0"
    kapp.k14s.io/versioned-cron-schedule-last-run: "2021-06-09T14:24:30Z"
  creationTimestamp: "2021-06-09T14:24:30Z"
  name: my-custom-resource-ver-9

That would just trigger a new versioning on a set interval, the timing would be dependent on kapp deploy being executed again. Basically if it has been +1 week since this kapp deploy was last run based on the "last run" in the annotation then my-custom-resource-ver-10 would be created.

Anything else you would like to add:

• This is designed to be run through kapp-controller, so the periodic running of kapp is implicitly provided.
• The other application not mentioned explicitly in this issue is cert-manager refreshing certificates without updating the associated secret, by triggering a new Certificate periodically before cert-manager refreshes a certificate you can pre-empt certificate refreshes.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[voor]

Some additional conversation on the topic: https://kubernetes.slack.com/archives/CH8KCCKA5/p1623341126453800

Some relevant improvements:

• Instead of all the complexity of cron schedules, just have something that can fit into ParseDuration
• Since versioned resources are created immutably, just leverage creationTimestamp instead of duplicating a field.
• Since annotation isn't really scheduled, just consider kapp.k14s.io/max-duration instead to make it a more intuitive.

[aaronshurley]

I'm going to move this issue to carvel accepted as the slack conversation elaborated details and use cases.

Priority of this is still TBD but it looks like some work may have started (#225). @cppforlife any updates on this?

[voor]

This issue has come up again recently in discussion again around cert-manager Certificate rotation.

[renuy]

thanks, @voor. Adding it to prioritized backlog. @praveenrewar let's discuss more and see if we can come with a proposal for this.

[kumaritanushree]

Acceptance Criteria:

• Kapp will have new annotation called kapp.k14s.io/max-duration which will accept duration string (like ParseDuration ) as value.
• Resource which has annotation kapp.k14s.io/max-duration set, kapp on every kapp deploy operation will create a new resource for that resource only if, CreationTimestamp + value of kapp.k14s.io/max-duration < current time (time.Now).
• For versioned resource kapp will create new resource with new version while for non-versioned resource kapp will delete existing resource and create new.

Can go through the doc for more details here

[renuy]

Proposal