good idea. however the application's ID is not meant to be user-supplied. maybe this could be called `deploymentId` and set (compare against) a config key called `deploymentId` ?
--a On 07/07/2017 16:33, Duncan Grant wrote:
I'd like to propose adding an appId parameter to the deploy endpoint. This would be optional and would presumably reject any attempt to start a second app with the same id. If set the appId would obviously be used in place of the generated id. This proposal would be of use in scripting deployments in a distributed environment where deployment is not the first step in a number of asynchronous jobs and would give us a way of "connecting" those jobs up. Hopefully it will help a lot in making things more robust for end-users. Currently, if the client’s connection to the Brooklyn server fails while waiting for a response, it’s impossible to tell if the app was provisioned (e.g. how can you tell the difference between a likely-looking app, and another one deployed with an identical blueprint?). This would make it safe to either retry the deploy request, or to query for the app with the expected id to see if it exists. Initially I'm hoping to use this in a downstream project but I think this would be useful to others. If no one has objections I'll aim to implement this over the next couple of weeks. On the other hand I'm totally open to suggestions of a better approach. Thanks Duncan Grant
