CC Matt Ingenthron Simon Murray

I need a great deal more information than is provided here; I will follow up with the dev team.

We do not need packaging, everything is downloaded directly from github. This allows it to be version controlled and updated with zero intervention by anyone. Manifests just change, the docs point to the current head of the branch, you don't need to ask Ceej to repackage it and then put it on a website.

I am unclear as to the requirements myself. The product is OSS, binary artifacts are generated on GitHub and made available to download. This project is operated as DevOps: issue is raised, issue is fixed, issue must be tested and then it is released, all in the space of a few hours potentially. Unlike operator, where customers have to wait months for a fix, this is nearly instant.

Is the ask here for you to take my, say 0.0.6, of the OSS project and rebrand it as 1.0.0-couchbase?

Assigning back to Roshani Sanghavi for required information. Please work out with the developers what exactly the need is here and, if a Docker image is needed, to develop a Dockerfile to represent the required output. Given that, we can work on creating a new manifest and build script, as necessary.

By way of demonstration... https://github.com/couchbase/service-broker/blob/master/documentation/modules/ROOT/pages/install/kubernetes.adoc note that the command is is a URL. This means any changes to the manifest are picked up instantly. It means that the documents never need to be changed (the one exception is for a versioned fork, which we will try to avoid).

Simon Murray Yes, we have to GA CSB as CSB 1.0 from the build version you would certify.

Chris Hillery Yes, I am discussing with the dev-team on this. There has been some confusion, but we are clear with it now.

As the earlier comments in this ticket are old, please confirm current direction before moving forward.  Here is a summary from recent Ops meetings that may provide useful direction.  Please confirm with PM on details:

1. CSB will be a separate product.  Target is for CSB v1.0 to launch with CAO 2.1 GA
2. EE only
3. Docs will move from current github to official docs
4. SB will be packaged as an official build and will be available for download on the DL page as a new product.  Mock-up pending.

Please refer to PRD for more info: Service Broker PRD

Roshani Sanghavi please review my comments here and provide updates if something is changed

Based on the above and from discussion with Wayne, I have filed CBD-3631 to track the Build requirements for this, namely item #2 in the original ticket Description. Item #1 regarding YAML file is a dev deliverable so can be tracked here or in a separate K8S ticket if desired.

I've also requested access to the PRD.

I'm currently operating under the assumption that the input source code is only the couchbase/service-broker repository, and the output artifacts for the build/release process are exactly a Docker Hub image and a Red Hat Container Catalog image with the name couchbase/service-broker . If there are other output artifacts (binaries, etc) that need to be shipped separately, please let me know. I saw that the repository has some control files for creating .deb and .rpm files, and I desperately hope that those are NOT intended to be shipped artifacts.

Also, FYI, it's far too easy to typo this as "service broken".

Lynn Straus, comments about your list:

"EE only" - is that meant to imply that it should become closed-source? Currently the source code repository is public, and is marked as Apache licensed.

"available to download on the DL page" - that's not accurate if (as I assume / hope) the output deliverables are Docker images.

Lynn Straus Thanks for describing it so well.
Chris Hillery I have shared the PRD with you!
Chris Hillery I have to edit the description. There are more than those 2 artifacts needs to be packaged together. Yes, we have to create .deb, .rpm, .tar, .zip files. Here is the URL for Reference - https://github.com/couchbase/service-broker/releases
Other Artifacts to be packaged together are listed below, & they are from the GitHub Repo - https://github.com/couchbase/service-broker
1. CRD - master/crds/servicebroker.couchbase.com_servicebrokerconfigs.yaml
2. Configuration - master/examples/configurations/couchbase-server/broker.yaml
3. Service Broker - master/examples/broker.yaml
4. Registerwith Service Catalog - master/examples/clusterservicebroker.yaml
5. Service Instance - master/examples/configurations/couchbase-server/serviceinstance.yaml
6. Service Binding - master/examples/configurations/couchbase-server/servicebinding.yaml

Simon Murray Please confirm 2 things as mentioned below -
1. Is Version 0.0.7 the final version with dev complete so that Ceej can make build out of it.
2. Are there any artifacts/yaml files missing in the list above which needs to be packaged in the build, if yes, please let us know.

Just fyi, adding all of those extra distribution mechanisms (rpm, deb, etc) makes this go from about a half-day effort to a solid week, possibly more. I will start on the Docker side for now but I will need to work with dev (probably Simon when he's back?) more closely on the remainder.

I filed CBD-3639 to track the non-Docker deliverables. I have put that into our next sprint (starting 9/21) as it is significantly more effort than can be inserted into the current sprint.

Roshani Sanghavi I don't know exactly what the scope of a PRD is, but that document does not cover the distribution requirements. For instance, the word "rpm" doesn't appear anywhere in there. It should also specify which Linux distributions we expect to support with those.

Simon Murray In the GitHub releases, there are .tar.gz and .zip files; what is the purpose of those? They appear to also be Linux binaries. Why is it necessary to have four different packages with the same contents?

Roshani Sanghavi Matt Ingenthron Is there any intent to support this binary for MacOS or Windows? The current GitHub releases do not seem to provide this.

Okay, clarity (from my point of view):

There are no "binaries" in the sense you are used to, only the broker executable, that is linux only.  99% of people will not even bother with packaging, just use the docker image and manifests directly from the CDN.  The entire point is to avoid packaging for the FOSS version al together and give a better end use experience.  The "packaging" is provided for users who "need" to build their own FOSS images, be that via archives or responsibly using version controlled packaging.  As such you should totally ignore what is happening on GitHub, that's for the community only.

Therefore IMO, build should philosophically just need to: create a makefile that clones the FOSS repo, runs make && make install with an "enterprise" badge, and spits out the normal make dist stuff, then do whatever you want afterwards.

That all said I have no idea what has been going on in my absence

And no 0.0.7 isn't your v1, if you want 2.14 API support that is going to be at least another few months given the operator needs to happen first, Connect, a whole heap of operator documentation etc.

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.

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.

Closing as a duplicate of SBEE-9