adds example using simple-app and downwardAPI #870
Conversation
| env: | ||
| #@overlay/match by="name" | ||
| - name: HELLO_MSG | ||
| value: #@ "hello from {} namespace, deployed by kapp-controller v{}, hosted on kubernetes v{}".format(data.values.ns, data.values.kcV, data.values.k8sV) |
There was a problem hiding this comment.
question: I was looking at code/docs of the develop branch to figure out if the downward API's versions are:
- prefixed with
v - always formatted as semver
But I couldn't find the answer, or I have not spend enough time on.
However, deployed by kapp-controller v{}, hosted on kubernetes v{} suggests that the versions won't be v-prefixed. Can you show the complete templated HELLO_MSG?
The reason I am asking is the under development proposal for @ytt:semver. Kapp-controller's downward API is a great use-case to consider, because the consumers of it could potentially benefit from semver operations in their ytt templates.
There was a problem hiding this comment.
that's a good idea - like you said, i put those 'v's in as hints but i should just show the result. :)
fwiw we did just merge a relatively easy-to-read unit test that shows the "v-less" nature of the version string:
https://github.com/vmware-tanzu/carvel-kapp-controller/pull/862/files#diff-67acaba412143ef942322b7b42729c6db75c89a1890b90fe0bc4801be8f71ab4R32
goal of the above little change was in fact to guarantee that consumers of this data as a string should always have a pretty vanilla "major.minor.patch" format without any of the decorative suffixes that creep in. So i think we're aligned in general. --- though looking at the example output, i guess that change was just for the kubernetes version
There was a problem hiding this comment.
So i think we're aligned in general
yay!
joe-kimmel-vmw
force-pushed
the
downapiexample2
branch
from
6a9d5e9 to
6ba55a8
Compare
No description provided.