In one case however, we do want to retain the same cluster id ( think
ingress on k8s  and thus SLAs with external touch points ) but it is
essentially a new job ( added an incompatible change but at the interface
level it retains the same contract ) , the only way seems to be to remove
the chroot/subcontext from ZK , and relaunch , essentially deleting ant
vestiges of the previous incarnation. And that is fine if that is indeed
the process.


On Fri, Feb 8, 2019 at 7:58 AM Till Rohrmann <trohrm...@apache.org> wrote:

> If you keep the same cluster id, the upgraded job should pick up
> checkpoints from the completed checkpoint store. However, I would recommend
> to take a savepoint and resume from this savepoint because then you can
> also specify that you allow non restored state, for example.
>
> Cheers,
> Till
>
> On Fri, Feb 8, 2019 at 11:20 AM Vishal Santoshi <vishal.santo...@gmail.com>
> wrote:
>
>> Is the rationale of using a jobID 000000* also roughly the same. As in a
>> Flink job cluster is a single job and thus a single job id suffices ?  I am
>> more wondering about the case when we are doing a compatible changes to a
>> job and want to resume ( given we are in HA mode and thus have a
>> chroot/subcontext on ZK for the job cluster ) ,  it would make no sense to
>> give a brand new job id ?
>>
>> On Thu, Feb 7, 2019 at 4:42 AM Till Rohrmann <trohrm...@apache.org>
>> wrote:
>>
>>> Hi Sergey,
>>>
>>> the rationale why we are using a K8s job instead of a deployment is that
>>> a Flink job cluster should terminate after it has successfully executed the
>>> Flink job. This is unlike a session cluster which should run forever and
>>> for which a K8s deployment would be better suited.
>>>
>>> If in your use case a K8s deployment would better work, then I would
>>> suggest to change the `job-cluster-job.yaml` accordingly.
>>>
>>> Cheers,
>>> Till
>>>
>>> On Tue, Feb 5, 2019 at 4:12 PM Sergey Belikov <belikov.ser...@gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> my team is currently experimenting with Flink running in Kubernetes
>>>> (job cluster setup). And we found out that with JobManager being deployed
>>>> as "Job" we can't just simply update certain values in job's yaml, e.g.
>>>> spec.template.spec.containers.image (
>>>> https://github.com/kubernetes/kubernetes/issues/48388#issuecomment-319493817).
>>>> This causes certain troubles in our CI/CD pipelines so we are thinking
>>>> about using "Deployment" instead of "Job".
>>>>
>>>> With that being said I'm wondering what was the motivation behind using
>>>> "Job" resource for deploying JobManager? And are there any pitfalls related
>>>> to using Deployment and not Job for JobManager?
>>>>
>>>> Thank you in advance.
>>>> --
>>>> Best regards,
>>>> Sergey Belikov
>>>>
>>>

Reply via email to