4:26 p.m.
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.
Regards,
--
PAVOL LOFFAY
Red Hat Česká republika <https://www.redhat.com/>
Purkyňova 111 TPB-B 612 45 Brno
M: +421948286055
<https://red.ht/sig>
8:19 p.m.
----- Original Message -----
From: "Pavol Loffay" <ploffay(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>, "tech-list" <tech-list(a)redhat.com>,
obsidian-team-list(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:51 p.m.
On 30/05/2017 11:19, Matt Wringe wrote:
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).
+1, this is what we have been doing on the Cloud Enablement team and the
3Scale team are now also adopting this approach after a recent
conversation we had with them.
Kev
--
JBoss by Red Hat
10:04 a.m.
On Tue, May 30, 2017 at 8:19 PM, Matt Wringe <mwringe(a)redhat.com> wrote:
----- Original Message -----
> From: "Pavol Loffay" <ploffay(a)redhat.com>
> To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>, "tech-list" <tech-list(a)redhat.com>,
> obsidian-team-list(a)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
Thanks for the response. We haven't thought about backports, just not yet.
I like setting the version as a template parameter it's a nice approach +1.
I maybe did not ask very specificly. My question shoud be: Would you use
not tagged images in public templates e.g.
https://github.com/jaegertracing/jaeger-openshift/pull/8#issuecomment-304...
We should guarantee that our templates work properly and that is only by
using tagged versions. If we don't use tag and IfNotPresent andministrator
has to do more steps to get a proper version or update.
I can see that you always suggesting using tagged images, which is the same
I think.
Regards,
>
> --
>
>
> PAVOL LOFFAY
>
> Red Hat Česká republika
>
> Purkyňova 111 TPB-B 612 45 Brno
>
> M: +421948286055
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
--
PAVOL LOFFAY
Red Hat Česká republika <https://www.redhat.com/>
Purkyňova 111 TPB-B 612 45 Brno
M: +421948286055
<https://red.ht/sig>
2522
days inactive
2522
days old
3 comments
3 participants
participants (3)
-
Kevin Conner -
Matt Wringe -
Pavol Loffay