Unable to update a jobs attributes if I have a known guid
shunte88 opened this issue · comments
Excellent solution and its ticking most of the boxes easily.
Having used enterprise level schedulers I'm looking for the facilities that many of these tools provide,
The ability to hold/fence a job is something that is often used, especially with complex interdependent scheduled jobs this is a must.
I noticed the disabled attribute on the job definition so tried flipping the attribute by performing a get on the job definition, an update of the attribute and a subsequent put.
This resulted in the old job under the original guid, and a new disabled job with its own guid
Job names aren't unique!?! Most folks don't live in the world of guids an majik numbers and we tend to talk to things by their name, job "Critical_ETL_Process_001" abended for example. We're using Bosun in conjunction with kala so I do have that facility.
What I am left with is two "parallel" setups, if I'd modified retries as an example I'd have two perfectly acceptable job definitions that could now execute and step on each other.
Scanning the code it looks like there's no update mechanism - everything is additive with the .Put
However given that internally the definition is being actively maintained with next run time and stats there's got to be something that could be taken advantage of in terms of functionality.
Could guid based updates be implemented for the base attributes?
Apologies for the run on, but the facility to run an abended job and have it retain and trigger dependencies seems to be missing too.
I'm sure the addition of a UI will bring these types of features together along with the underlying functionality
And yes these do step beyond the simple cron-like functionality but you guys have already gone above and beyond that already
Having dug into api.go I've found some of the features I spoke to exposed as endpoints
/api/v1/job/disable/{guid}
/api/v1/job/enable/{guid}
/api/v1/job/start/{guid}
Perfect!
So it's just the non-unique names that "seems" to be an issue, I reviewed the Chronos implementation and they have a hard rule around nomenclature.
Fantastic work guys, and very much appreciated.
@shunte88 Glad you like it! Let me know if you have any further questions. :)