Can you verify if the object (i.e. the version) got updated when the command executes successfully but the pods are not recreated, the old one is left as is running the old version? You can use `kubectl get -f your-config.yaml -o yaml` to check if the image version has been updated.
On Thu, May 11, 2017 at 10:11 AM, Tim Hockin <thoc...@google.com> wrote: > You can either anonymize (like change the image name) or you can send > it to me directly - thockin@google and I will pass it on to the folks > who know that logic best. > > Tim > > On Thu, May 11, 2017 at 8:40 AM, Kristian Freed > <kristian.fr...@gmail.com> wrote: > > Client version used is 1.5.4 against master 1.6.2, nodes version 1.6.1. > > > > I should be able to produce some examples for repro, but would prefer to > not > > share in the open, could you please send me an email to my first name dot > > last name on google mail to arrange for an exchange? :) > > > > On Thursday, 11 May 2017 15:57:03 UTC+1, Tim Hockin wrote: > >> > >> What kubectl version? Can you show an example YAML pair that doesn't > >> apply ? There have been bugs in the patch-generation logic in the > >> past, but I think they are all resolved. > >> > >> On Thu, May 11, 2017 at 6:12 AM, Kristian Freed > >> <kristia...@gmail.com> wrote: > >> > Hi, > >> > > >> > We have an automated deployment flow that uses kubectl apply -f to > >> > upgrade > >> > the version of services running in our test and production > environments. > >> > The > >> > file applied is templated with a version that is injected into the > >> > container > >> > image path, so that the only difference between the file used between > >> > deployments is the version/tag part of the docker image. > >> > > >> > Normally this runs without any problems, but occasionally, the change > >> > just > >> > isn't applied - the command executes successfully but the pods are not > >> > recreated, the old one is left as is running the old version. > >> > > >> > This behaviour is especially confusing as no error is reported, all > >> > scripts > >> > report success but the wrong version of a service is left running in > the > >> > cluster. > >> > > >> > It appears to be deterministic, in that going back to an older > version, > >> > then > >> > applying the same updated file, always fails silently. If I was to > >> > guess, it > >> > would appear to be some type of hash collision where a change is not > >> > detected. > >> > > >> > Has anyone else observed this behaviour? > >> > > >> > Cheers, > >> > Kristian > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups > >> > "Kubernetes user discussion and Q&A" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> > an > >> > email to kubernetes-use...@googlegroups.com. > >> > To post to this group, send email to kubernet...@googlegroups.com. > >> > Visit this group at https://groups.google.com/group/kubernetes-users. > >> > For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Kubernetes user discussion and Q&A" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to kubernetes-users+unsubscr...@googlegroups.com. > > To post to this group, send email to kubernetes-users@googlegroups.com. > > Visit this group at https://groups.google.com/group/kubernetes-users. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
