should we be using CRD openapi v3 schema validation for the status section

[huizengaJoe]

Does it make sense to use CRD openapi v3 schema validation for the status section as a way to enforce consistency in naming the binding items?

It would be great if we had a way to:

1. Know/Discover that a service supported binding
2. Add some tooling like a new operator-sdk scorecard test/linting rules that could check for consistent binding item names.... for those services that support binding

Thoughts?

[arthurdm]

hey @huizengaJoe - I really like the idea of having an operator-sdk scorecard test that would check for spec compliancy. Is that something we could contribute somewhere?

I am not sure if that necessarily means something in the OAS3 schema, since from what I have seen that's mostly to validate spec values that users would input in the CR. It's not to say it's not possible, I just don't know if it fits the common usage of OAS3 validation.

[arthurdm]

hey @huizengaJoe - for your first point, I believe that will get addressed by PR #9 - please feel free to add comments there.

[nebhale]

@arthurdm Is this issue still valid for the current state of the specification?

[scothis]

@nebhale it's stale since the CRD instance (which contains the schema) needs to be provided by the implementation.

[arthurdm]

I guess the valid question is: should the spec provide a CRD for ServiceBinding, so that every implementation does not have to create one?

[nebhale]

As in a reference implementation Go library?

[arthurdm]

I was thinking just the CRD itself, since we may have non-Go implementations.

[nebhale]

What concrete artifacts do you think this should be then? Just an OpenAPI schema definition?

[arthurdm]

I was thinking the full CRD, including the OAS3 portion. Before the restructure of the spec we were pointing to this CRD, which was nice in terms of having a concrete CRD that implementations could share. Was looking for something equivalent.

[scothis]

I guess the valid question is: should the spec provide a CRD for ServiceBinding, so that every implementation does not have to create one?

The CRD definition is inextricably linked to the implementation since the versions severed and storage flags as well as the conversion webhook are defined on the CRD resource. The most the spec can do is provide an exemplar CRD resource, but it should not be directly used by an implementation.

[arthurdm]

ya, if >90% of the CRD will be the same, would be nice to provide it in the spec.

[nebhale]

OK, I'll start work on a PR for an exemplar CRD.