Editing A Running Deployment

[jason-magnetic-io]

Goal:

Editing one or more of the following parameters in a deployment should trigger an update of the associated service or services in Marathon

• services.breed.deployable.definition
• services.breed.ports
• services.breed.environment_variables
• services.environment_variables
• services.scale.cpu
• services.scale.memory
• services.scale.instances

Current Behaviour:

• When editing the source of a running deployment, only changes to scale (cpu, memory, instances) trigger an update to the service in Marathon.
• Changes to other parameters are ignored.
• If other parameters, for example services.breed.environment_variables, are changed at the same time scale is changed. The changes to the other parameters are not passed to Marathon.
• Changing any parameter other than scale results in the deployment showing as deploying in the UI. Eventually the deployment transitions to deployed but the service in Marathon is not updated.

[jason-magnetic-io]

@dragoslav how can this be best achieved?

[dragoslav]

During deployment sync these changes can be detected and specific request can be sent to container driver. Now it is only about updating/deleting, this should be a restart (or update with restart) - new feature. In case of ports, environment variables etc. scheduler must restart existing instances (containers). In case of changing the scale just number of instances is changed and traffic is not interrupted - assuming at least one instance can still handle it.

[dragoslav]

In case of Rest API, when a blueprint is edited there is no side effect on any deployment. That means if blueprint is later merged again, in this example with change of ports, vars etc. deployment services may be restarted unintentionally. I would add an extra check, e.g. only if restart=true flag is set proceed, otherwise request is invalid - in case of UI an user would need to confirm the restart.