---
title: "Writing a Proposal on: kapp deploy triggers a new versioned asset based on a predetermined interval"
authors: [ "Kumari Tanushree <[e-mail]>" ]
status: "In progress"
approvers: [ "Praveen Rewar <[e-mail]", "Soumik Majumdar <[e-mail]>" ]
---
###### tags: `kapp`

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

## Problem Statement
There is a requirement from user to have a feature in `kapp deploy` to trigger a new version of a resource on pre-defined interval ([ref](https://github.com/vmware-tanzu/carvel-kapp/issues/224)).

## Proposal

**New annotation:**
1. kapp.k14s.io/renew-duration = duration (1h, 2s, 3m)
3. kapp.k14s.io/last-renewed-time = <current time> (used by kapp internally, to indicate an update in resource and for non-versioned resources with update-strategy != always-replace will be used to match the condition as creationTime don't update with the update in these resources)

**Changes:**
1. Validate value for annotation kapp.k14s.io/renew-duration (if set). If invalid, error out at diff stage only.
2. if **current_time - creationTimestamp > renew-duration**, add annotation kapp.k14s.io/last-renewed-time if not already added otherwise update kapp.k14s.io/last-renewed-time = <current time>.
3. if **current_time - creationTimestamp < renew-duration**, kapp will work as it is working currently.
4. For Versioned resources, kapp will create new resource(same as it working now whenever there is any new update).
5. For non-versioned resource, resource will get updated as per the update-strategy has been set for it.
6. Also if **creationTimestamp < last_renewed_time** (value of ann kapp.k14s.io/last-renewed-time) then last-renewed-time will be used to validate the condition. Condition will be **current-time - last_renewed_time > renew-duration**.

**Drawbacks:**
For **non-versioned** resources with update-strategy != always-replace:

1. if there is long time difference in diff and actual update to the res in the cluster(could happen due ordering of resources by kapp) then next update might happen early than it should be as we update last-renewed-time annotation before diff.

2. if user makes an update before duration expired, kapp won't update last-renwed-time annotation, as at diff stage it is difficult to find resource with update apply operation in current code base.

**Solution:**

User can use **always-replace** as update strategy for non-versioned resources.

### Specification / Use Cases
**Use case:** Have some use cases around cert manager where certain apps dont reload secrets and configmaps automaticaly but use cert manager and lets encrypt certs. By having this feature in `kapp deploy` would make sure our apps reload the new certs from cert manager before they are invalid.