Aled- Should this be applicable to all POST/DELETE calls? Imagine an `X-caller-request-uid` and a filter which caches them server side for a short period of time, blocking duplicates.
Solves an overlapping set of problems. Your way deals with a "deploy-if-not-present" much later in time. --A On 25 July 2017 at 17:44, Aled Sage <aled.s...@gmail.com> wrote: > Hi all, > > I've been exploring adding support for `&deploymentUid=...` - please see > my work-in-progress PR [1]. > > Do people think that is a better or worse direction than supporting > `&appId=...` (which would likely be simpler code, but exposes the Brooklyn > internals more). > > For `&appId=...`, we could either revert [2] (so we could set the id in > the EntitySpec), or we could inject it via a different (i.e. add a new) > internal way so that it isn't exposedon our Java api classes. > > Thoughts? > > Aled > > [1] https://github.com/apache/brooklyn-server/pull/778 > > [2] https://github.com/apache/brooklyn-server/pull/687/commits/5 > 5eb11fa91e9091447d56bb45116ccc3dc6009df > > > > On 07/07/2017 18:28, Aled Sage wrote: > >> Hi, >> >> Taking a step back to justify why this kind of thing is really >> important... >> >> This has come up because we want to call Brooklyn in a robust way from >> another system, and to handle a whole load of failure scenarios (e.g. that >> Brooklyn is temporarily down, connection fails at some point during the >> communication, the client in the other system goes down and another >> instance tries to pick up where it left off, etc). >> >> Those kind of thing becomes much easier if you can make certain >> assumptions such as an API call being idempotent, or it guaranteeing to >> fail with a given error if that exact request has already been accepted. >> >> --- >> >> I much prefer the semantics of the call failing (with a meaningful error) >> if the app already exists - that will make retry a lot easier to do safely. >> >> As for config keys on the app, in Duncan's use-case he'd much prefer to >> not mess with the user's YAML (e.g. to inject another config key before >> passing it to Brooklyn). It would be simpler in his case to supply in the >> url `?appId=...` or `?deploymentId=...`. >> >> For using `deploymentId`, we could but that feels like more work. We'd >> want create a lookup of applications indexed by `deploymentId` as well as >> `appId`, and to fail if it already exists. Also, what if someone also >> defines a config key called `deploymentId` - would that be forbidden? Or >> would we name-space the config key with `org.apache.brooklyn.deploymentId`? >> Even with those concerns, I could be persuaded of the >> `org.apache.brooklyn.deploymentId` approach. >> >> For "/application's ID is not meant to be user-supplied/", that has >> historically been the case but why should we stick to that? What matters is >> that the appId is definitely unique. That will be checked when creating the >> application entity. We could also include a regex check on the supplied id >> to make sure it looks reasonable (in case someone is already relying on app >> ids in weird ways like for filename generations, which would lead to a risk >> of script injection). >> >> Aled >> >> >> On 07/07/2017 17:38, Svetoslav Neykov wrote: >> >>> 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 <duncan.gr...@cloudsoftcorp.com> >>>> 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 >>>> >>> >> >> >
