Bootstrap should detect task def changes
slpsys opened this issue · comments
Right now, the bootstrap command detects if there is a most-recent task definition, but only tries register_task_definition if there is nonesuch. In reality, calling register_task_definition creates a new version of the task definition; it'd be likely useful to detect this, because...quite frankly, most people are going to mess things up at least once.
not sure what this means exactly? you want to register a new task definition anyways when people bootstrap?
calling register_task_definition twice on task definition my_def yields task definitions my_def/1 and my_def/2 in ECS. Broadside currently will always check if any my_def/* exists, and if so, never update. It will update the service, just not the task definition. This is suggesting that if you run bootstrap twice, it updates the task definition in some way, or at least detects it.
This is suggesting that if you run bootstrap twice, it updates the task definition in some way, or at least detects it.
do you mean "if you run bootstrap twice, it SHOULD update the task definition?"
FWIW any kind of deploy will update the task definition to match the configuration; it's only bootstrap that won't.
This is suggesting that if you run bootstrap twice, it updates the task definition in some way, or at least detects it.
i am in favor of the idea that running bootstrap twice will delete the service and make a new one based on what is configured (though maybe it would be a decent idea to add a --force flag to actually do that, and without --force it just warns and says it won't update if it detects any differences between the configured service_config and the actual current service config in AWS)
do you mean "if you run bootstrap twice, it SHOULD update the task definition?"
Yes. Which, apparently, everything else does?
FWIW any kind of deploy will update the task definition to match the configuration; it's only bootstrap that won't.
I didn't actually notice that when I was poking around, but that actually kind of makes the current bootstrap behavior more annoying. For e.g. ELBs, the Task Definition and the Service need to be in lockstep, and no command other than bootstrap allows you to set up an ELB, since only create_service allows this. If you mess up the Task Definition the first time, broadside will never allow you to correctly set up an ELB/Service without going outside the tool.
re: your other comment, I haven't thought much about it, but it does seem like --force might be useful.
how about this behavior:
if bootstrap fails, deactivate the created task definition
bootstrap will not overwrite a task definition if it exists, and will not overwrite a service
if the force flag is provided, both the task definition and service will be overwritten
if bootstrap fails, deactivate the created task definition
presumably you mean "if bootstrap fails to create the service AND already created a task definition"?
yea
i meant to answer "sounds good to me as long as it sounds good to marc, he seems to have a clearer grasp of the use case