Uploaded image for project: 'Couchbase Kubernetes'
  1. Couchbase Kubernetes
  2. K8S-1557

Packaging & Distribution of Couchbase Service Broker

    XMLWordPrintable

Details

    • 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

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            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?

            ceej Chris Hillery added a comment - 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?

            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.

            ceej Chris Hillery added a comment - 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.

            ceej Chris Hillery added a 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.
            simon.murray Simon Murray added a comment -

            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 Simon Murray added a comment - 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 Simon Murray added a comment -

            Closing as a duplicate of SBEE-9

            simon.murray Simon Murray added a comment - Closing as a duplicate of SBEE-9

            People

              simon.murray Simon Murray
              roshani.sanghavi Roshani Sanghavi (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty