Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define ServiceAvailable condition #218

Merged
merged 1 commit into from
May 14, 2022

Conversation

scothis
Copy link
Contributor

@scothis scothis commented Apr 8, 2022

Add a ServiceAvailable condition to the ServiceBinding status.
Logically, the behavior covered by the ServiceAvailable condition is a
subset of the existing Ready condition. The behavior of the Ready
condition is unchanged.

The status is True when the referenced Provisioned Service is resolved
and exposes a binding secret. The status is False if the Provisioned
Service cannot be resolved, either because it does not exist, or is not
visible to the implementation. The status is Unknown when the
referenced Provisioned Service is resolved, but does not expose a
binding secret.

When managing the rollout of resources that include a service, binding
and workload it can be difficult today to observe each resource to know
when there is a problem that requires remediation.

  • It is common (and often desirable) for a workload to crash if a
    required service is not available.
  • The Ready condition will be False if the workload does not exist

The above cases make it difficult for tools to observe the health of
either resource during the rollout, while the resource will eventually
settle on a healthy status, a circuit breaker could flip in the interim
that reverts the rollout. With a new ServiceAvailable condition we can
stagger the rollout of the resource to upsert the service and binding,
wait for ServiceAvailable to become True and then upsert the
workload.

Additionally, if the workload is immutable (like a Job), the creation of
the workload must be held until the service is known to exist. The
ServiceAvailable condition becoming True can signal that it's ok to
create the workload. If the workload is created before the service is
available, the ServiceBinding won't be able to complete the binding.

Signed-off-by: Scott Andrews andrewssc@vmware.com

Add a `ServiceAvailable` condition to the `ServiceBinding` status.
Logically, the behavior covered by the `ServiceAvailable` condition is a
subset of the existing `Ready` condition. The behavior of the `Ready`
condition is unchanged.

The status is `True` when the referenced Provisioned Service is resolved
and exposes a binding secret. The status is `False` if the Provisioned
Service cannot be resolved, either because it does not exist, or is not
visible to the implementation. The status is `Unknown` when the
referenced Provisioned Service is resolved, but does not expose a
binding secret.

When managing the rollout of resources that include a service, binding
and workload it can be difficult today to observe each resource to know
when there is a problem that requires remediation.
- It is common (and often desirable) for a workload to crash if a
  required service is not available.
- The `Ready` condition will be `False` if the workload does not exist
The above causes make it difficult for tools to observe the health of
either resource during the rollout, while the resource will eventually
settle on a healthy status, a circuit breaker could flip in the interim
that reverts the rollout. With a new `ServiceAvailable` condition we can
stagger the rollout of the resource to upsert the service and binding,
wait for `ServiceAvailable` to become `True` and then upsert the
workload.

Additionally, if the workload is immutable (like a Job), the creation of
the workload must be held until the service is known to exist. The
`ServiceAvailable` condition becoming `True` can signal that it's ok to
create the workload. If the workload is created before the service is
available, the ServiceBinding won't be able to complete the binding.

Signed-off-by: Scott Andrews <andrewssc@vmware.com>
@scothis scothis requested a review from a team April 8, 2022 01:31
@scothis
Copy link
Contributor Author

scothis commented Apr 8, 2022

More details of the problem and reproducible test cases are available in carvel-dev/kapp#427

Copy link
Contributor

@baijum baijum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@arthurdm arthurdm merged commit 24fff89 into servicebinding:main May 14, 2022
@scothis scothis deleted the service-available-condition branch May 14, 2022 13:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants