Add netbox_deploy Ansible role for deploying NetBox via Argo CD

[Copilot]

• Explore existing deploy roles to understand patterns
• Create simplified netbox_deploy role following synology_csi_deploy pattern
• Reduce argument_specs to 4 required inputs only (superuser_password, secret_key, kubeconfig, context)
• Remove Longhorn storage references, use local-path provisioner instead
• Hardcode sensible defaults in templates (namespace, argo project, chart version, tailscale annotations)
• Verify templates render correctly
• Pass ansible-lint validation

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Deploy Netbox helm chart</issue_title>
<issue_description>https://github.com/netbox-community/netbox-chart

Deploy NetBox Argo Application with proper configuration

Goal
Create a new Ansible role that deploys NetBox to the homelab k3s cluster via an Argo CD Application resource, following the same patterns and quality bar as the existing deployment roles:

• ansible/roles/homepage_deploy
• ansible/roles/longhorn_deploy
• ansible/roles/tailscale_operator_deploy
• ansible/roles/synology_csi_deploy

This role should render a complete, production-ready Argo CD Application spec using the upstream, vendor official NetBox Helm chart, wired cleanly into the existing HA k3s + Tailscale + Longhorn + Synology stack.

Scope
This issue is only for:

• Creating ansible/roles/netbox_deploy
• Defining its argument specs and defaults
• Rendering the NetBox Argo Application YAML and Helm values into the standard artifacts tree
• Optionally applying the Application (if that matches the pattern of the existing deploy roles)

It does not cover seeding NetBox data, custom device models, or migration tooling beyond what the chart already provides.

Role structure and conventions
Follow the same structure and conventions as the existing *_deploy roles:

• ansible/roles/netbox_deploy/meta/argument_specs.yml
• ansible/roles/netbox_deploy/defaults/main.yml
• ansible/roles/netbox_deploy/tasks/main.yml

Rules:

• Use fully qualified collection names for all Ansible modules.
• All variables for this role must be prefixed with netbox_deploy_.
• The role must be idempotent and pass Ansible lint.
• Use the existing role_artifacts role exactly the same way other deploy roles do to determine where rendered files are written.
• Keep tasks minimal and focused. If concerns start to mix (generic Argo tooling vs NetBox specifics), that is a sign for future, separate roles rather than overstuffing this one.

Argo CD Application spec requirements
Use Argo CD’s official Application spec as the reference.

The role should:

1. Render a complete Argo Application manifest for NetBox:

   • apiVersion: argoproj.io/v1alpha1

   • kind: Application

   • metadata.name: netbox

   • metadata.namespace: Argo CD’s namespace (derived or provided the same way as the other deploy roles).

   • spec.project: the same Argo project used for other homelab apps.

   • spec.source:

     • Use the vendor official NetBox Helm chart repository and chart name.
     • Use the latest stable chart version by default, overridable via netbox_deploy_helm_chart_version.
     • Configure Helm values through spec.source.helm.valuesObject (see Helm section below).

   • spec.destination:

     • server: in-cluster API server, consistent with the other deploy roles.
     • namespace: netbox by default, driven by netbox_deploy_namespace.

   • spec.syncPolicy:

     • Follow the same sync policy pattern (automated/manual, syncOptions, retry) as the existing homelab application roles.

2. Write the Application YAML to the artifacts directory using role_artifacts:

   • Follow the same structure as the other application deploy roles. For example:

     • .artifacts/{{ deploy_env }}/argo/applications/netbox-application.yaml

   • All output paths are derived from role_artifacts outputs, not hard coded.

3. Optionally apply the Application to the cluster:

   • Provide netbox_deploy_apply_application (bool) to control whether the rendered manifest is applied.
   • If true, apply using kubernetes.core.k8s or a tested kubectl flow that matches existing patterns, including any CLI prerequisites those roles enforce.

Helm configuration and values
Use the official NetBox Helm chart from the upstream vendor. Configure the Application spec.source.helm like this:

• netbox_deploy_helm_repo_url: default to the official NetBox chart repo.
• netbox_deploy_helm_chart_name: default to the correct NetBox chart name.
• netbox_deploy_helm_chart_version: default to the latest stable, but overridable.

Overrides rule:

• Only put overrides in spec.source.helm.valuesObject.
• If the chart’s default for a value is sufficient, do not set it in valuesObject.
• netbox_deploy_values_overrides should be a dict that is merged directly into valuesObject and used as the single source of override truth.

Values must:

1. Respect the HA k3s layout:

   • Ensure the application and its backing components (web, workers, Redis, Postgres, etc., depending on how the chart is structured) schedule cleanly in an HA k3s environment.
   • If the chart exposes pod distribution controls (affinity, topology spread, podAntiAffinity), expose minimally necessary overrides via netbox_deploy_values_overrides when needed, but do not re-state defaults.

2. Integrate with Longhorn and Synology:

   • For stateful NetBox components (database, Redis persistence if...

• Fixes Deploy Netbox helm chart #17

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[SRF-Audio]

@copilot This is a good start, but it's over-parameterized. I'll be deploying this into my homelab as a permanent fixture, with occasional updates. I really only need inputs for knobs that I would truly want to alter here and there...not absolute flexibility.

Also, Longhorn is now out of my architecture, so it'll just be the local provisioner and Synology.

Set sensible defaults, and inherit from inventories/group_vars whereever you can.

[Copilot]

@copilot This is a good start, but it's over-parameterized. I'll be deploying this into my homelab as a permanent fixture, with occasional updates. I really only need inputs for knobs that I would tru...

Simplified the role in f32981e. Now only requires 4 inputs: netbox_deploy_superuser_password, netbox_deploy_secret_key, k8s_validator_kubeconfig, and k8s_validator_context. Removed Longhorn - now uses local-path provisioner. Hardcoded sensible defaults (namespace, argo project, helm chart version, tailscale annotations) in templates following the synology_csi_deploy pattern.