onyx

FYI: alternative Onyx :onyx: chat is at <https://gitter.im/onyx-platform/onyx> ; log can be found at <https://clojurians-log.clojureverse.org/onyx/index.html>
sparkofreason 2018-06-16T17:06:16.000062Z

For handling redeployments of an ongoing job, I've been manually assigning the a new job ID, using the previous job ID to look up the job snapshot coordinates, which is then used to create the resume point for the updated job. I have a feeling I'm making this too hard. How is this generally handled?

lucasbradstreet 2018-06-16T17:13:16.000104Z

In the last year we added the ability to lookup the job history by a :job-name that is supplied in the job map

lucasbradstreet 2018-06-16T17:14:01.000033Z

You can use https://github.com/onyx-platform/onyx/blob/0.13.x/src/onyx/api.clj#L298 to get the job-id / tenancy history, or even better get the snapshot coordinates by name here https://github.com/onyx-platform/onyx/blob/0.13.x/src/onyx/api.clj#L308

lucasbradstreet 2018-06-16T17:42:03.000041Z

The latter is smart enough to deal with cases where a job never managed to successfully checkpoint e.g. deployed with a bug

lucasbradstreet 2018-06-16T17:42:16.000046Z

It walks back until it finds a snapshot

sparkofreason 2018-06-16T17:48:33.000111Z

Nice

sparkofreason 2018-06-16T21:58:09.000044Z

Thanks, that's a big improvement over what I was doing before.

lucasbradstreet 2018-06-16T21:59:57.000112Z

Great. Had to dog food the resume stuff a bit before coming up with a good pattern for that 🙂

lucasbradstreet 2018-06-16T22:00:47.000060Z

If you’re multi node and submit on startup you’ll still want to inject a stable job-id into all of your peers, but other than that it should just work

lucasbradstreet 2018-06-16T22:08:34.000046Z

I’ll try to work that into the resume point onyx example