-
Bug
-
Resolution: Unresolved
-
Major
-
None
Greetings, in the DC/OS 1.9.1 version of Marathon, calling PUT `/v2/apps/group/appname` with an intent to restart the app fails silently when the app is already deployed. In the past, this API would successfully restart an app that was already deployed. It no longer seems to do this.
Instead, POST `/v2/apps/group/appname/restart` must be called. See discussion at https://dcos-community.slack.com/archives/C052AG7RQ/p1500894363012384.
Apologies if the severity of this is incorrect, there is no workaround for this issue. Please adjust it according to community standards if it is set incorrectly. Thanks!
[JENKINS-45752] Updating existing app with same definition requires /restart API
Just wanted to updated others with a workaround that colinmsphere helped me find today.
- First, note there is a Jenkins environment variable that is set by most SCM providers indicating a build identifier. With Git, it is accessible in configuration via `${GIT_COMMIT}`. This variable is usable directly in the configuration UI for Jenkins.
- Next, have your build (whether through the Jenkins Docker plugin or whatever you use within your build system tag your Docker builds with the full identifier that would be returned by the SCM provider on Jenkins. Such a URI might look like `registry.example.com/example/project:34a78f0cdf1e9b9fb897c4533e63b471e8aecfad`.
- Now, in the configuration for the Marathon Deployment plugin for a build, click "Advanced..." and set the "Docker image" field to `registry.example.com/example/project:${GIT_COMMIT}`.`
When this build runs, the Docker image field overwrites any app configuration specified with a unique value. The unique value triggers the existing Marathon REST endpoint to behave as a `POST /restart` would, but but using the `PUT /update` that the current Jenkins plugin uses.
Brian Topping
added a comment - - edited Just wanted to updated others with a workaround that colinmsphere helped me find today.
First, note there is a Jenkins environment variable that is set by most SCM providers indicating a build identifier. With Git, it is accessible in configuration via `${GIT_COMMIT}`. This variable is usable directly in the configuration UI for Jenkins.
Next, have your build (whether through the Jenkins Docker plugin or whatever you use within your build system tag your Docker builds with the full identifier that would be returned by the SCM provider on Jenkins. Such a URI might look like `registry.example.com/example/project:34a78f0cdf1e9b9fb897c4533e63b471e8aecfad`.
Now, in the configuration for the Marathon Deployment plugin for a build, click "Advanced..." and set the "Docker image" field to `registry.example.com/example/project:${GIT_COMMIT}`.`
When this build runs, the Docker image field overwrites any app configuration specified with a unique value. The unique value triggers the existing Marathon REST endpoint to behave as a `POST /restart` would, but but using the `PUT /update` that the current Jenkins plugin uses. 
If I read the discussion correctly, the [marathon] application definition being sent to marathon is the same as what marathon already has deployed. In this case, marathon does not see a change and does not trigger a new deployment.
The use case in this ticket is a new version of the docker container being made available on an existing version/tag and needs to be force pulled by the marathon application. ("dockerimage:latest") If this is incorrect, please let me know.
A work around, for now, would be to version docker images and have that version updated by the plugin ("Docker Image" field in the config UI). This field is able to handle Jenkins parameters and variables.