It seems to be some issue with deployment controller. Any GitHub issue opened for this?
+Janet On Fri, May 12, 2017 at 2:18 AM, Kristian Freed <kristian.fr...@gmail.com> wrote: > We've tried the command and can confirm that the right version (docker > image) *is* reported, but the running pod has not been recreated and is > still running a different version. > > Additionally, simply deleting the pod does still re-creates it with the > previous version. > > On Thursday, 11 May 2017 21:20:16 UTC+1, Mengqi Yu wrote: >> >> 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 <tho...@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 >>> <kristia...@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/grou >>> p/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-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.
