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.
The text was updated successfully, but these errors were encountered:
kvmw
changed the title
AppDeploymentUpdateServiceInstanceWorkflow is trying to update a service-instance without backing application or backing service. AppDeploymentUpdateServiceInstanceWorkflow is trying to update a service-instances without backing application or backing service.
Feb 21, 2022
Consider a service definition
foo
with backing appfoo-backing-app
and a backing servicefoo-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 allfoo
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.
The text was updated successfully, but these errors were encountered: