First wave of specification adopters

[arthurdm]

This issue will list the first few specification adopters that we'll work with.

• Service Binding Operator
• Runtime Component Operator
• Strimzi Operator
• PostgreSQL Operator
• IBM Cloud Operator
• OpenShift Do (odo)

Once there's an existing issue or PR created on the corresponding GitHub repo of the project, please add a comment here for tracking purposes.

[arthurdm]

Service Binding Operator:

• adoption of annotations (ref)
• A modification to its API group, to be independent from OpenShift. (ref)
• A simplification of its CRD name to ServiceBinding (we are already using this name in the spec). (ref)
• Renaming customEnvVar to dataMapping. (ref)
• Allowing for the application selector to be omitted, for the cases where another Operator owns the deployment. (ref)
• Not related to the CRD, but directly related to how this spec approaches item 1 from Pointer to binding data, in terms of referencing a nested property. (ref)
• Make service-binding-operator work on vanilla k8s. (ref)

[arthurdm]

Strimzi Operator

• General improvements to bindable data. (ref)

[arthurdm]

Runtime Component Operator

• Adoption of various parts of the spec. (ref)

[ron1]

Would it make sense to include S3 Bucket binding via an ObjectBucketClaim in this initial wave of spec adopters since this is a common use case and is supported in the following upstream Red Hat-maintained community operators

• lib-bucket-provisioner
• awss3operator
• noobaa
• rook-ceph

as well as the downstream Red Hat OpenShift Container Storage operator?

[arthurdm]

hey @ron1 - sure, the more adoption the better =)

I guess in terms of "first wave" vs "subsequent waves" relates to resources we have available to work through this. The current 5 Operators listed either have resources committed to work through it or at least a commitment that we'll get to it (either RH or IBM) in the near-term (in the next month or so).

Do you think you would be able to help drive the S3 Bucket adoption?

[ron1]

hi @arthurdm - I'm not sure I have the necessary contacts to fully drive the S3 Bucket adoption but I am willing to help.

[arthurdm]

awesome, thanks @ron1

do you have a link to the main operator that drives the ObjectBucketClaim binding?

[ron1]

@arthurdm The source code for the lib-bucket-provisioner library that drives the ObjectBucketClaim binding is available here: https://github.com/kube-object-storage/lib-bucket-provisioner. This morning, I noticed that this library was given a DEPRECATION NOTICE last month. As described in the README, There is a Kubernetes Enhancement Proposal under review which will significantly change this design and interfaces. This repo is not longer active and should not be used.

The KEP has been a work-in-progress since November 2019 but now seems to be nearing completion. It will likely take a while for this KEP to be implemented and subsequently integrated into products. What are your thoughts about moving forward with this in the meantime?

[arthurdm]

Thanks for the info @ron1 - I would suggest we target this for the second wave of adoption, which hopefully matches well with this KEP moving forward. Could you please add a comment in here so we don't lose track of this service?

[arthurdm]

hey @navidsh / @yharish991 - could you guys please take an initial look into what changes would be needed for the PostgreSQL Operator to adopt the spec? Could be a lower bar for now.

[ron1]

hi @arthurdm - I added the comment on the second wave of adoption issue here.

[arthurdm]

IBM Cloud Operator

• Adoption of spec annotations. (ref)

[sbose78]

redhat-developer/odo#2161 should we track this here too?

[arthurdm]

agreed @sbose78 - added in the description. will add an entry here too.

[arthurdm]

odo

• List and provision services. (ref)

[arthurdm]

Closing this in favour of #82 and #83, as the items on this issue have become outdated.