Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
None
-
1
Description
Packaging and Distribution
1. Couchbase Service Broker YAML file has to be packaged with Operator in CAO 2.1 release
Here are the files needs to be packaged together listed below, & they are from the GitHub Repo -https://github.com/couchbase/service-broker :
I. CRD - master/crds/servicebroker.couchbase.com_servicebrokerconfigs.yaml
II. Configuration - master/examples/configurations/couchbase-server/broker.yaml
III. Service Broker - master/examples/broker.yaml
IV. Registerwith Service Catalog - master/examples/clusterservicebroker.yaml
V. Service Instance - master/examples/configurations/couchbase-server/serviceinstance.yaml
VI. Service Binding - master/examples/configurations/couchbase-server/servicebinding.yaml
2. Couchbase Service Broker image has to be Published to Docker and RedHat Registry
3. .deb, .rpm, .tar, .zip files need to be created as its created here - https://github.com/couchbase/service-broker/releases
Attachments
Activity
Roshani Sanghavi Based on Simon's comments that there will not be a release of CSB for several months, I have dropped CBD-3631 from our current sprint and CBD-3639 from the next sprint into our backlog. There isn't a further action to be taken until there is clarity and agreement on at least the questions in my last comment.
Simon Murray Roshani Sanghavi Just discovered a new issue. The Docker Hub release vector for this EE CSB image would have to be named couchbase/service-broker . However, that repository already exists and contains images for the FOSS version. I'm not sure how to unstick that.
The EE images will be named couchbase/service-broker:X.Y.Z , which is the same tagging convention used by the FOSS images. Also there can only be one "latest" tag, which would be pointing to the most recent EE version.
Something else to think about.
In all honesty I'm happy to use ghcr.io (now it exists), as it removes a layer of red tape, for the FOSS images. Your other option is to use a revision e.g. 1.0.0-enterprise1 to denote deviation from the main branch and patches thereupon if you wish to cohabit.
Simon Murray I'm afraid your message has utterly confused me. I'm assigning this back to you; could you please try again? Let's start with the release deliverables and work backwards from there.
When it is time to release this product, what artifacts should be generated? RPMs? Debs? Zips? If any of those, what precisely needs to be contained within them?
When it is time to release this product, do we need to create a Docker image? If so, what precisely needs to be in it? Is the Dockerfile that is in the repo "correct" in terms of building a releasable image?