Consolidate charm-microceph with MicroCeph docs

[skoech]

Description

This PR consolidates charm-microceph docs with the MicroCeph docs in this repository, inspired by the style in the Canonical Kubernetes docs, like this:

1. Creates two sub-directories, under microceph/docs/, and name then snap/ and charm/.

• This is where the actual content for MicroCeph and charm-microceph, respectively, will live.

2. Each section will have its own index.rst file, with a hidden toctree.
3. The navigation structure is defined in this index.rst’s toctree, like this:

.. toctree::
   :hidden:
   :titlesonly:

   Deploy from Snap package <snap/index>
   Deploy with Juju <charm/index>

4. Then, there are be Diataxis components under each sub-directory. For now, we’ll only have the tutorial and how-to components in the charm sub-directory, because that is the only documentation we have on the repository.

Type of change

• Documentation update (change to documentation only)

How has this been tested?

I have built and served the changes locally, and verified that the documentation builds and renders as expected:

Contributor checklist

• self-reviewed the code in this PR
• added code comments, particularly in less straightforward areas
• checked and added or updated relevant documentation
• checked and added or updated relevant release notes
• added tests to verify effectiveness of this change

[johnramsden]

Suggested change

	in charm-microCeph.
	in charm-microceph.

[johnramsden]

Suggested change

	Install and deploy charm-microCeph
	Install and deploy charm-microceph

[johnramsden]

Suggested change

	Deploy a charm-microCeph cluster with Juju.
	Deploy a charm-microceph cluster with Juju.

[johnramsden]

Regarding versioning, I think the way that would mirror how we would do something if it were a software release would probably be a git tag that corresponds to a release - https://docs.readthedocs.com/platform/latest/versions.html.

One complexity here is this might tie the two documentation types together (c-mc & mc would be on one tag)

And then other than that the idea seems good to me. Looks like some work still needs to be done on syntax and the rst so I won't comment there

[skoech]

Good catch on charm-microceph naming, thanks @johnramsden. I've done away with that and now sticking to just MicroCeph as the product name(with different ways of deploying).
As for versioning, using git tags corresponding to releases seems like the way to go. I think it's OK to have the same tag for both mc & c-mc since the risk channels correspond to each other, and we can just have a stable version for both of them. But I'm happy to discuss about this some more.

[sabaini]

Hey @skoech in general I'm +1 on the plan, one thing I wonder about is committing the charm-microceph docs into this repo though.

Aiui it's still the plan that the canonical source of truth for the charm-microceph docs still is the charm-microceph repo, is that correct? If that is the case I'd prefer not to duplicate them into this repo but download / pull them on demand only, i.e. when docs are built. Otherwise we'd risk overwriting our own changes. Hope I'm not missing sth

[skoech]

@sabaini, you're right. I've removed them and modified the script to fetch them from the charm-microceph repo at RTD build time.