docs: include server deployment in public documentation

[rene-oromtz]

Description

This is a long needed PR to add the server deployment to the public documentation. Historically, this has been in our private documentation but this PR has been generalized enough so it can be useful for partners attempting to deploy Testflinger Server.

The Testflinger Agent Host already is public so making this public as well with the following pages:

1. Deploy a Testflinger Server
2. Maintain a Testflinger Server

Resolved issues

Documentation

This add the server deployment guide following the same pattern as agent deployment

Web service API changes

Tests

Manually tested the server deployment via Juju CLI in a multipass environment

[Copilot]

Pull request overview

Adds public “Testflinger server” deployment and maintenance documentation to the Sphinx docs, aligning it with the existing agent-host admin documentation.

Changes:

• Adds a new “Administer Testflinger server” how-to section with deployment and maintenance guides.
• Updates the how-to index to surface the new server administration documentation.
• Minor cleanup in shared documentation links.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
docs/reuse/links.txt	Fixes formatting/line placement for the Ubuntu Discourse link entry.
docs/how-to/index.rst	Adds the server administration section to the how-to toctree.
docs/how-to/administer-server/index.rst	New index page for server administration guides.
docs/how-to/administer-server/deploy-testflinger-server.rst	New Juju-based deployment guide (CLI + Terraform path).
docs/how-to/administer-server/maintain-testflinger-server.rst	New maintenance guide (refresh + secrets enablement).

Comments suppressed due to low confidence (1)

docs/how-to/administer-server/deploy-testflinger-server.rst:238

• Grammar: “it is user responsibility to setup …” should be rephrased (e.g., “it is the user’s responsibility to set up …”).

  The Terraform module will only deploy the Testflinger server charm, it is
  user responsibility to setup a Terraform plan that deploys the Ingress charm
  and configures the required relations. For a sample Terraform plan, 

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ajzobro]

The diagram might benefit from slightly larger arrowheads (double in size) and a bit less whitespace directly in the middle.

[ajzobro]

Is this only for the current, i.e. a specific, version of juju? Should we also be specifying that version?

[rene-oromtz]

The version is not necessary, only the strict version is needed. It could be a greater version (latest is 1.36-strict/stable) but there is no latest-strict/stable channel :(

[tang-mm]

This version number can quickly become unmaintainable. How about using a placeholder like <latest_version>-strict?

[tang-mm]

Thanks for the much-needed addition! Glad to see the server docs becoming public :)

My main suggestion is a small cleanup on the deployment guide, as it currently mixes how-to steps with some explanation/reference material. I think it would be easier to follow if the page stayed more task-focused, with the architecture/background linked from a more detailed context (which will potentially be completed later when we consider more components)

[tang-mm]

The architecture is useful context here, but this section feels a bit too explanatory for a how-to task. Would you consider moving most of the “Architecture” section to a new page (e.g. “Architecture” under Explanations) and keeping only a short introductory paragraph here? something like:

Testflinger server runs as a Kubernetes application and uses MongoDB as its backend. In this guide, MongoDB is deployed as a machine charm and connected to the server through a Juju cross-model relation. For more details, see [architecture page]

This could keep this page more focused on the required actions

[tang-mm]

This version number can quickly become unmaintainable. How about using a placeholder like <latest_version>-strict?