Add the Chronicle Server chart

[AlexMapley]

Background

Part of https://github.com/rstudio/chronicle/issues/683.

We are migrating this from a private posit repo, where we've been hosting the chart previously.

Summary

• Migrates the chronicle chart to this repo
• Updates with rstudio helm best practices, standard features
• Update the global file charts/_templates.gotmpl
• Adds ci components and documentation

Notes

This PR is still an early draft, though I'd like to get some early feedback if possible and open the PR now for discussion

I've added a number of new features to the chronicle chart like pod tolerations, affinities, nodeSelectors, etc. - though i didn't add every feature under the sun. I'm on the lookout for more basic features we think the chronicle chart should include

[CLAassistant]

All committers have signed the CLA.

[AlexMapley]

@colearendt @shahmonanshi what do you 2 think of this chart in its current form?
Are there others you might think we'd benefit from tagging as reviewers? I wasn't sure who else to add.

I've added you as a reviewer too @tnederlof as I see you've been making some cross cutting changes to this repo as well

[colearendt]

Just a few nits. Totally fine to update at a later date 😄 I try to avoid Statefulsets if possible, but if you have a good reason to use them (slower to roll over, etc. etc.), then carry on!

[colearendt]

Interesting!! Why is a Statefulset important? Is that for a caching disk or some such?

[AlexMapley]

It's mostly as a convenience for the pvc provisioning, if you're running with local storage enabled Persistent storage a pvc is a must-have for most use cases. It's nice to not have to worry about duplicate replica sets being created on helm updates as well, the pod replacement policy of stateful-sets is generally simple and non-problematic for chronicle.

Theoretically we could run chronicle on a deployment/replica-set model, there's not too many technical blockers to think of. The stateful-set model has worked well so far though

[colearendt]

That makes sense.

It's worth noting that statefulsets do have some downsides: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#limitations

Usually services that uses statefulsets have a particular reason to do so. Otherwise replicasets/deployments are the more standard choice.

If you use a PVC, does each chronicle node store its own data? Or do they share data storage?

[AlexMapley]

That's tough, we do have a choice to make for sure. As a developer I feel like it's nice to have those pvcs deleted by default:

Deleting and/or scaling a StatefulSet down will not delete the volumes associated with the StatefulSet. This is done to ensure data safety, which is generally more valuable than an automatic purge of all related StatefulSet resources.

Though on the other hand, we are trying to build a data archive too. If we scaled a chronicle server from 1->5 replicas for a day, and stored a bunch of data, it would be nice if 2 weeks later when we tried scaling 1->5 again we found our old data in those local storage systems that we could add to.

If you use a PVC, does each chronicle node store its own data? Or do they share data storage?

Yeah each chronicle server does need a dedicated pvc, that's a known technical limitation right now in the alpha though. We need to rewrite some in-memory locks into file-locks for our compactor engine, and then we can support nfs or shared storage. We'll definitely need to make some helm changes around that too.

[AlexMapley]

This conversation has made me think of an epic though that the chronicle team should probably undertake: https://github.com/rstudio/chronicle/issues/715.
I made a note there about looking into deployments vs. statefulsets and seeing what's more practical in our testing

[tnederlof]

Looks good, just some comments about using the latest tag.

[SamEdwardes]

Nice work! I left a few nit-picky comments. Where ever we can drive consistency across the other products I think it is very helpful for our end users!

P.s. I have yet to try to deploy the helm chart, but I plan to. I will update this PR once I am done to report if I run into any issues.

[AlexMapley]

Thanks everyone for all for your feedback! I don't think I disagree with anything, I tried to make 80-85% of the adjustments suggested and made a note of the rest with some github issue tracking.

• Most notably from @SamEdwardes, we're now using pascal case for our config values and following other shared config conventions.
• @tnederlof your comments pushed us to make a new release, and we now tag against the 2023.11.2 docker image
• We have a new epic around your nfs comments @colearendt, we've definitely been thinking about supporting nfs too post this launch