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.
  • [kubernetes-users]... Kristian Freed
    • Re: [kubernet... 'Tim Hockin' via Kubernetes user discussion and Q&A
      • Re: [kube... Kristian Freed
        • Re: [... 'Tim Hockin' via Kubernetes user discussion and Q&A
          • R... 'Mengqi Yu' via Kubernetes user discussion and Q&A
            • ... Kristian Freed
              • ... 'Mengqi Yu' via Kubernetes user discussion and Q&A
                • ... 'Janet Kuo' via Kubernetes user discussion and Q&A

Reply via email to