You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider a service definition foo with backing app foo-backing-app and a backing service foo-backing-service.
When a service-instance creation fails for any reason, there might be situations which we have the service-instance (in failed state) but the backing-app and/or backing-service has not been created. So even though service-definition says that every service-instance has a backing-app and a backing-service, there are service-instances without one or both of them. In this case any attempt to update/upgrade above service-instance will fail because AppDeploymentUpdateServiceInstanceWorkflow is not able to find the backing app or service.
This is especially troublesome when upgrade all services operations (batch). for example, when a new version of foo is available and we are trying to update all foo service-instances to the new version.
One way to solve this issue is by changing the AppDeploymentUpdateServiceInstanceWorkflow.accept method to reject service-instances without backing app or service (in failed state).
Another way would be handling the missing backing app / services gracefully during update.