Add MicroK8s instructions to CONTRIBUTING.md

[monrax]

Add MicroK8s instructions to CONTRIBUTING.md for testing locally with both Linux and macOS.

In addition, this PR introduces the updates/docs branch. The idea is to have one place where we can modify README.md, CONTRIBUTING.md, and other docs in one place before merging with main.

We should always rebase before merging. Thus, the workflow would be:

git checkout updates/docs
git pull --rebase
# make some changes to README
git add README.md
git commit -m "fix: typo in values reference"
git fetch origin
git rebase origin/main
git push --force-with-lease

Then,

• Open a PR
• Add reviewers, only if required
• Make sure to rebase/squash again, only if necessary
• Merge away!

Of course, let's say an urgent last-minute modification to the README is due, admins can always bypass all of this and push directly to main. Other contributors would have to go to the procedure specified above.

[williamtrelawny]

@monrax Great instructions! My feedback:

• Overall, I feel like this should all be in the main README, or perhaps a separate doc specifically for setting up a lab/poc environment, which would be really useful to users. I understand those looking to contribute would need such an env so instructions here could make sense too, but there will likely be plenty of non-contrib users wanting to deploy a poc env as well, so to me the instructions for setting up a poc env belong in a more general-scoped location.
• I think the validating and upgrading instructions should be in the main README because it's crucial information for users not too familiar with Helm. Or again if you think it better to make a "beginner's guide" or some other secondary doc to go over these concepts that aren't exclusive to our Chart.
• Lastly, I like the naming of the quicksetup options. Do you think there would be any difference between a "small" production configuration vs a POC deployment's configuration? If so, perhaps we should introduce a "poc" quicksetup value. Prob best if we talk more on this live, including larger quicksetup options.

[monrax]

Thank you @williamtrelawny ! OK, one by one:

1. I see your point. These kind of instructions usually live in CONTRIBUTING.md since we expect regular chart users to already have their clusters up and running before trying the Graylog chart. We can link to the "Setting up a MicroK8s cluster" section of CONTRIBUTING from the README, or we can also have a separate "setting-up-microk8s.md" file with those instructions and link to it from both CONTRIBUTING, and README files. I think unless we plan to use that doc on its own elsewhere, we can prob skip separating it from CONTRIBUTING for now.
2. Unless chart users are making modifications to the chart, everything in the README assumes the chart is "read only". There should be no changes to validate coming from beginners or POCs. Eventually, the idea is to set up our own chart repository, and at that point remove the clone-this-repo step. Then install/upgrade commands won't use graylog ./graylog, but instead graylog graylogrepo/graylog. Still, no template rendering/validation is required. I believe this should stay in CONTRIBUTING.
3. I just put that together as a quick way to set up the replicas for both Graylog and Datanode at the same time, but perhaps there's a better way to do this. In any case, I agree: the values allowed for quicksetup (or size, or presets) is out of scope for this PR. Let's sync on this later this week.

Please, let me know if this sounds right.

[williamtrelawny]

Please, let me know if this sounds right.

All sounds good to me! Thanks @monrax

[williamtrelawny]

LGTM!

[monrax]

Sorry, forgot to mention it: don't delete the updates/docs branch! We can keep it as a staging ground for changes to docs (README, CONTRIBUTING, etc) before pushing them to main (just remember to rebase onto main to avoid drift, if required).

Also, please remember to rebase/squash before merging with main. This helps avoid merge bubbles.

[williamtrelawny]

Sorry, got carried away clicking all the Github buttons. I knew you meant to not delete the branch but that blasted button was calling my name...

But I didn't think about rebasing so thanks for that, I'll be more careful going forward 😅