Hi Duncan, I've solved this problem before by adding a caller generated config key on the app (now it's also possible to tag them), then iterating over the deployed apps, looking for the key.
An alternative which I'd like to mention is creating an async deploy operation which immediately returns an ID generated by Brooklyn. There's still a window where the client connection could fail though, however small it is, so it doesn't fully solve your use case. Your use case sounds reasonable so agree a solution to it would be nice to have. Svet. > On 7.07.2017 г., at 18:33, Duncan Grant <[email protected]> > 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
