feat: add horizon theming support

[Guno327]

Companion PR to:
https://review.opendev.org/c/openstack/sunbeam-charms/+/986671/

Exposes the added horizon-k8s charm functionality via the sunbeam configure command.
Due to limitations of the juju terraform provider the custom-theme resource is attached out of band and ignore by terraform entirely. One might think this would effect the persistence of the resource, but that is not the case in practice.

Tested extensively on both local and MAAS providers; changes are functional and persistent, even across cluster refresh.

Testing was done by publishing the above linked horizon-k8s revision to a custom track on charmhub due to the limitation of juju terraform provider preventing specifying a local path to a charm as the source for the deployment. As such it would be advisable to wait for the horizon-k8s charm PR to land in a published charm channel before attempting to test this PR.

[Guno327]

Functional test failure expected as upstream charm support is not released.

[gboutry]

As we discussed earlier on the charm PR, we need to manage this lifecycle.

We should have a cluster key to register the attached resource version, and give to the terraform plan:

  resources = {
    "custom-theme" : <resource-number>
  }

(resources will need to be exposed on the tf plan)

[Copilot]

Pull request overview

This PR exposes Horizon theme configuration through sunbeam configure by adding a new interactive step that can attach a Horizon custom-theme resource via Juju and then apply the corresponding Horizon charm config via the openstack-plan Terraform plan.

Changes:

• Added a new AttachHorizonThemeStep to prompt for theme options, attach the custom-theme resource, and apply Horizon config through Terraform.
• Wired the new step into both MAAS and local provider configure command flows (with an openstack-plan init).
• Added a JujuHelper.attach_resource() helper to run juju attach-resource against a model/application.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.

File	Description
sunbeam-python/sunbeam/steps/horizon.py	New step implementing Horizon theme prompting, Juju resource attachment, and Terraform-based config application.
sunbeam-python/sunbeam/provider/maas/commands.py	Adds openstack-plan init + Horizon theme step to MAAS configure.
sunbeam-python/sunbeam/provider/local/commands.py	Adds openstack-plan init + Horizon theme step to local configure (control nodes only).
sunbeam-python/sunbeam/core/juju.py	Adds attach_resource() helper for attaching a Juju resource to an application.

---

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

[hemanthnakkina]

I am thinking in the lines of proxy command... having a separate Step to apply horizon theme as part of sunbeam cluster deploy in maas mode, sunbeam cluster bootstrap in manual mode after DeployControlPlaneStep which should prompt/or take values from manifest.

For day-2 operations, we can have

sunbeam dashboard theme set
sunbeam dashboard theme clear

@gboutry Thoughts?

[gboutry]

I think we need both. One that gets triggered by the manifest, for reproducible deployments, and the full CLI experience.

[Guno327]

As we discussed earlier on the charm PR, we need to manage this lifecycle.

We should have a cluster key to register the attached resource version, and give to the terraform plan:

  resources = {
    "custom-theme" : <resource-number>
  }

(resources will need to be exposed on the tf plan)

After much testing I have confirmed that this is not possible with local resources. The terraform providers claim that revision numbers are supported is exclusively in reference to charmhub hosted resource revision numbers.

Any time I try to assign a resource by revision from a local file upload terraform would complain with:
"value of "custom-theme" should be a valid revision number or image URL."
I tried passing the revision number in various formats for several hours with no luck.

After taking a step back I realized that my attached resource always had a revision number of "0", no matter how many times I ran this.

It turns out local files ALWAYS have a revision number of 0. As such the juju terraform provider rejects revision number 0 (only accepts positive int) because it only supports charmhub hosted resources (as I initially suspected).

[Guno327]

I think we need both. One that gets triggered by the manifest, for reproducible deployments, and the full CLI experience.

Latest version moves the theming logic into the deploy/bootstrap time (with full manifest support) as well as exposes day 2 sunbeam dashboard theme set and sunbeam dashboard theme clear commands. Due to the overlap with existing commands I migrated the sunbeam dashboard-url command to sunbeam dashboard url and merged its file with my added one for the day 2 commands.

[wolsen]

@Guno327 The failure in the latest run appears to be a real failure. Can you please review and take a look. There's an error deploying the Horizon theming step.

[Guno327]

@wolsen This is the same expected failure as before. Terraform apply craps out because the upstream horizon-k8s charm does not yet have the config values that terraform is trying to set yet. Even when no custom theme is applied the terraform plan still explicitly sets the default values for these config options (to support clearing existing config in the case of day 2 ops).

Before it did not appear until a later stage as that was when the horizon theming took place, now that it takes place inside the bootstrap phase that is when the terraform crash happens.