Skip to content

[do not merge] hacked in some features: extra CSS + default-exclude ingresses#12

Open
cdanis wants to merge 7 commits intoarch-anes:mainfrom
cdanis:hack
Open

[do not merge] hacked in some features: extra CSS + default-exclude ingresses#12
cdanis wants to merge 7 commits intoarch-anes:mainfrom
cdanis:hack

Conversation

@cdanis
Copy link
Copy Markdown

@cdanis cdanis commented Jan 14, 2025

Hi, thanks very much for your work on this :) I made some modifications for my own use.

This probably shouldn't be merged as-is but thought I'd send a draft in case you were interested in more work on either of these.

@abelfodil
Copy link
Copy Markdown
Contributor

Thank you for your contribution @cdanis! Could you please split this PR into two? One for the operator refactor and another one for the stylesheet.

Both changes LGTM on the surface but I'd like them split out to review properly! :D

@abelfodil
Copy link
Copy Markdown
Contributor

Could you please elaborate on the default-exclude ingresses part? Ideally, we should be able to customize default behaviour via env variables

@cdanis
Copy link
Copy Markdown
Author

cdanis commented Jan 17, 2025

Could you please elaborate on the default-exclude ingresses part? Ideally, we should be able to customize default behaviour via env variables

So ultimately I'd like to run multiple instances of the operator, so I can have a few different dashboards generated from the same underlying resources. This will probably require some other rethinking too, but I hadn't gotten that far yet.

Env vars sound good instead of flags for passing in config settings, and that would also eliminate the need to have a central state object, which might be desirable. Certainly keeps the patches shorter.

If I have time this weekend I'll split out the CSS patch (and improve its Helm-ization).

@abelfodil
Copy link
Copy Markdown
Contributor

So ultimately I'd like to run multiple instances of the operator, so I can have a few different dashboards generated from the same underlying resources. This will probably require some other rethinking too, but I hadn't gotten that far yet.

I see. I think we should redesign the operator to handle this use-case. It was thought of in terms of a single instance for the entire cluster.

Here's one approach:

  1. Add a homer.instance_id annotation which identifies the instance in question.
  2. Pass the instance_id as an env var to the operator.
  3. Any entry that is not annotated with the specific instance_id will be ignored.

This way you could simply spawn multiple operators and Homers via Helm and you could target how these instances will be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants