Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

@k8s-bot I signed it!

CLAs look good, thanks!

@a-robinson any suggestions on how we guage the production readiness of this example? It would be great if we could run something like jepsen on the kube+cockroach app stack (I'm guessing just any old 3 tier nginx -> app -> postgres db but with cockroach should work). We're currently at the point where we don't know if what we have is sufficient to run production ready dbs yet. Figured it would be easiest to start by productionizing some more modern examples like cockroach/etcd.

Maybe this will require a seperate cockraoch-kube repo where people can bang at it, report issues etc, and we upstream feature requests (kind of like https://github.com/CyCoreSystems/etcd-petset)? or can we go straight to charts like: helm/charts#37?

Re certs: what creates the secrets in a normal deployment? can you describe the issue a bit more.

@a-robinson any suggestions on how we guage the production readiness of this example? It would be great if we could run something like jepsen on the kube+cockroach app stack (I'm guessing just any old 3 tier nginx -> app -> postgres db but with cockroach should work). We're currently at the point where we don't know if what we have is sufficient to run production ready dbs yet. Figured it would be easiest to start by productionizing some more modern examples like cockroach/etcd.

Either our acceptance tests or our jepsen tests could work for that purpose. I'm not sure how much work would be required to get the jepsen tests running in k8s though. @knz may have a better idea of how custom of a setup is needed to get them running?

Maybe this will require a seperate cockraoch-kube repo where people can bang at it, report issues etc, and we upstream feature requests (kind of like https://github.com/CyCoreSystems/etcd-petset)? or can we go straight to charts like: helm/charts#37?

A separate repo or a chart would be fine by me. Although the chart contributors guide mentions that charts shouldn't use alpha features, so we'd have to fudge the rules a bit to do that.

Re certs: what creates the secrets in a normal deployment? can you describe the issue a bit more.

The operator typically would create them on their local machine and then distribute them when dropping the binaries onto each instance. There's a quick walkthrough in our docs. As you mentioned on #28446, there are certainly more dynamic ways that it could be done at startup if needed.

On an unrelated note, I won't be able to fix the release-note label, since apparently my labeling privileges went away recently :(

Re setting up jepsen tests. The test framework require

• the cockroach binary and a couple of utilty programs copied to the VM/container
• a SSH daemon enabled, and a user account that can log into it remotely with passwordless key auth,
• passwordless sudo for that account. sudo is used to change the system clock (via ntpdate and a custom program) and invoke tcptump, which also need to be available.

Thanks, that all sounds pretty manageable, with the SSH part perhaps being a little awkward.

@k8s-bot test this github issue: #30714

LGTM, I think we should get together a working group of people interested in getting {db of choice} on kube and have them run {acceptance tests} at least once as a starting point. I'm going to propose something along these lines at sig-apps or a community meeting. Let me know if you have anyone on your side interested.

Sorry for the small modification, I just ensured all resources had the app=cockroachdb label and added a brief blurb about how to clean up the resources when you're done.

Also, looks like the 1.4 code freeze is in pretty full effect, so should we assume that this won't be merged until mid-September?

LGTM, I think we should get together a working group of people interested in getting {db of choice} on kube and have them run {acceptance tests} at least once as a starting point. I'm going to propose something along these lines at sig-apps or a community meeting. Let me know if you have anyone on your side interested.

Yeah, I'd be happy to be part of that group from our side. I'll also check into running acceptance tests on top of Kubernetes sometime in the next couple weeks.

Hey @a-robinson @bprashanth!

We now have an incubator folder in the charts repository for any charts that require features that are currently in alpha.

We would love to have this added to incubator and then promoted to stable (along with the others) when PetSets are in Beta.

SGTM
A recurring question: what is fair grounds for the charts repo? the minikube.sh script in this example? dockerfiles for custom init containers? or is the answer "treat your charts subdir like a private repo"?

@bprashanth

For the most part whatever you need to make the chart useful. You can setup a .helmignore file to exclude files, like Dockerfiles. A solid README (already included here) is required and the chart should install with sane defaults. Once kubernetes/minikube#541 is merged in you can use a dynamically provisioned PVC for the minkube testing and shouldn't require that script anymore.

An example of the PVC pattern can be found in the MySQL chart:
helm/charts#46

Thanks @viglesiasce, I'll take a look at getting cockroachdb set up there soon.

@bprashanth is there anything you need from me to re-LGTM this?

Awesome @a-robinson! Looking forward to it.

Oh, sorry for the delay I assumed you were moving it but getting this in as is SGTM

GCE e2e build/test passed for commit 98b6d06.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit 98b6d06.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue