docs: Mimir on Juju docs

[sinapah]

Issue

Based on: grafana/mimir#15202.

Solution

Checklist

• I have added or updated relevant documentation.
• PR title makes an appropriate release note and follows conventional commits syntax.
• Merge target is the correct branch, and relevant tandem backport PRs opened.

Context

Testing Instructions

Upgrade Notes

[YanisaHS]

Ok I've made a lot of high-level feedback, so have fun 😅

LMK if you have questions or want to discuss!

[lucabello]

TODO (self): follow up with @YanisaHS on the IA question — the how-to root currently mixes product-level guides (Deploy and manage, Integrate, Migrate, Configure and tune, etc.) with component-level guides for individual charms (the three Mimir on Juju docs added in this PR). Need her input on the cleanest way to separate the two concerns without duplicating the Diátaxis structure per component.

[YanisaHS]

@lucabello Happy to discuss this more in depth but I’m also going to hijack your self TODO and chime in 😈

As I see it, there’s three concepts worth separating here (using Mimir as the example):

• COS-centered deployment: Full COS solution is the main product context to the user, Mimir is one component inside it, but includes other components for the full solution.
• Mimir-centered deployment: Mimir is the main product context to the user, using Juju/COS charms adds the operational model only, includes whatever other components are needed for that
• Mimir (charm): The specific charm that deploys/configures Mimir, it’s not a deployment path

I’m noting that because I wouldn’t consider Mimir on Juju as “component-level” for Observability, to me it’s still at the end-user product-level. Not trying to nit, but just so we’re on the same page with why I’ve made my suggestions below

And there’s the other consideration that (1) we need Diataxis top-level in the sidebar, and (2) the Mimir on Juju docs only have how-tos now, but that could change later

Easiest solution (least disruptive, if you want to get this out soon and figure out the optimal IA later)

Keep the pages where they are, add an entry point somewhere as Explanation that links to all the existing pages. It's not ideal since the user loses the navigation as soon as they leave that page, but it would give you an entry point if you need to link to one.

AND

Also have a manually-added small navigation block in every Mimir on Juju page that links to all the relevant docs (e.g., at the top, below the intro). You could reuse the content here with Sphinx instead of manually coping it per page. This would give every user of the page a connection to all the Mimir on Juju docs

Potential actual solution (if there’s not that many “[Product] on Juju” pathways)

Add a separate section like “Product deployment paths” (or “Product-centered deployment paths”, just “Deploment paths”, etc…) to each relevant Diataxis section, like

How-to guides
    Deploy and manage
    Integrate
    Configure and tune
    Validate and troubleshoot
    Product deployment paths
       Mimir on Juju
          Deploy Mimir on Juju
          Connect object storage to Mimir on Juju
          Send metrics to Mimir on Juju
       [example] Loki on Juju
       [example] Tempo on Juju

And (if needed later) add “Product deployment paths” as another under Explanation or Reference. E.g.,

Explanation
   Product deployment paths
      Mimir on Juju
         [Mimir on Juju explanation]

I have some reservations about this because “Product deployment paths” isn’t matched with the action-based categories of the existing section and it’s a lot of nested clicks for the user, but trying to work with what we have. This way still gives them the docs together in the sidebar, keeping them in a more “isolated” section.

Very open to hearing other thoughts/suggestions though! It’s a fun problem 🎉 🎈 😊

[YanisaHS]

Content looks good though✨