1 Answer
- Newest
- Most votes
- Most comments
0
Job definitions (much like ECS task definitions) are versioned. This means there isn't one task/job def where you can apply standard CRUD operations but rather you are creating a new revision. When you use the job def it will use the "latest" rev by default OR you can specify a previous revision. Correct me if I am wrong but the workflow you'd use isn't tremendously different between an "update" or a "register/create" (considering that the way you will launch it won't change because it will by default always run your last rev)?
Relevant content
- asked 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
The Batch API does not provide a function to create a new revision.
I think what you are saying is one must read the JobDefinition, modify only the docker image name, and then write the result using the
registerJobDefinition()
function. This also means one should ignore drift on the CFT stack that created the JobDefinition in the first. place. Do I have that right?Yes Batch does not provide a way to update a job def (IIRC ECS does not provide one either for tasks def and what you see on the ECS console when you
create a new task rev
is just a UI facility that imports the old one and then register the new one under the same task def name with the rev at +1).I can think of a couple of ways to do this (assuming you deployed with CFN): 1) read the job def, change the image name (or likely the tag?), ignore the drift. Or 2) update the CFN stack with the new image name/tag (this will save you from reading the job def and seeing the drift but will force you to do updates via CFN).
Let's see if someone can chime in with better ideas.
(1) is ok, except some will not like 'ignore the drift'. It also could lead to inadvertent errors or races with someone updating the CFT/CDK. (2) as I mentioned in my comments is unacceptable due to very slow iteration time (and developer separation of concerns for that matter).
Consider a feature request to allow the image (or at least tag) to be overridden in the Job, just like environment variables. That would make the image late binding, which is what it should tends to be, unlike say the VPC or IAM permissions.