Keller, Jens <jens.keller@...>
thanks for your feedback - comments inline.
Not sure if my understanding is correct. First of all, to avoid misunderstandings, it'd be totally fine if we had an asynchronous mechanism. We don't need the operation to be synchronous. Second, if that's a new API, that's absolutely fine as well, we understand & agree that incompatible changes are not the way to go.
But the point here is, whether the return code is correct or not is not so much our issue: the issue is that we currently do not see any reliable way of knowing whether the route mapping worked or not, or is still in progress. So how do we know when we can disconnect the old version? See also the next comment below. So agree, just polling the route until the app returns a 200 is not the way to go (also see below).
Given we have a lot of instances of the old version, and just created one or a few instances of the new version on the same route - how do we even know that the route mapping worked at all?
Even when waiting for 5 minutes, it could be we get a 200, just because the response came from the old version, so we think it works, but when we now disconnect the old version it'd be fatal. And if we get a 404, how do we know whether we need to wait for 5 minutes, or the mapping just failed entirely and there's no point in waiting any longer at all.
To me that would feel a bit like "add a wait that is hopefully long enough and cross fingers" - I'm afraid such an approach is not really acceptable for enterprise applications with business-critical processes. But not sure if I got you wrong.
I'm not sure which changes to the router would be possible and which won't - but I assume if it is possible to tell the router "please map X", it should be possible to add a feature, with which one could ask the router "what's the status of the mapping operation of X"?
The cloud controller could then just provide a new API that exposes this, so that a deployment script can poll this information – or am I missing something?