[Hawkular-dev] Openshift/k8s templates, tagged images vs IfNotPresent

[Matt Wringe]

----- Original Message -----
> From: "Pavol Loffay" <ploffay at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>, "tech-list" <tech-list at redhat.com>,
> obsidian-team-list at redhat.com
> Sent: Tuesday, 30 May, 2017 10:26:20 AM
> Subject: [Hawkular-dev] Openshift/k8s templates,	tagged images vs IfNotPresent
> 
> Hi,
> 
> we are providing OpenShift and k8s templates for Jaeger project
> https://github.com/jaegertracing .
> 
> What is the "standard" in the industry when providing public templates?
> Should we use tagged versions of images or depend on IfNotPresent strategy
> (pull image when not present)?
> 
> I would say that public templates should use tagged versions because it's
> always tested against a specific version and therefore guaranteed that it
> works as expected. This also seems to be the case templates provided by
> fabric8 team. Another thing is that templates not using tagged versions
> might get quickly outdated.
> 
> IfNotPresent may lead to weird states when a template is not compatible with
> pulled image. Plus it does not allow to simply update deployment when using
> tagged templates.
> 
> I'm just interested in what people think and use.

If you are doing releases where you are not going to be doing backports, I would say just set it to a specific version and use the default 'IfNotPresent' policy.

If you are doing releases where you are going to be backporting issues, I would say to set it to a version alias and use the 'Always' policy.

Eg for versions in which you provide backports:

If your release is 1.2.0, then you would have an image tagged as 1.2.0 and also one tagged as v1.2. Your template would be set to the default v1.2 version (tip: have the version set as a template parameter and not hardcoded so that its easy to configure)

Let's say you need to backport a fix and how you are at 1.2.1, so now you tag your image 1.2.1 and again with v1.2 (which will overwrite the v1.2 version so that it always points to the latest 1.2.x release)

If your template is using v1.2 as the image tag, you will just need to restart your pod for the new image to be fetched and the pod will be using the updated containers (deploymentconfigs may also help here to automatically redeloy when a new image is available).

If your user doesn't not want to automatically bring in the backported image with fixes (say they have a requirement to test each new image in a staging environment before pushing to production) then they can set the template parameter to '1.2.0' or some other specific version which shouldn't change. This will also allow a user to rollback a release to 1.2.2 if they are having a problem with 1.2.3

> 
> --
> 
> 
> PAVOL LOFFAY
> 
> Red Hat Česká republika
> 
> Purkyňova 111 TPB-B 612 45 Brno
> 
> M: +421948286055
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>