-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unified HTML landing page (NOT a dashboard!) #531
Conversation
willcl-ark
commented
Sep 4, 2024
•
edited
Loading
edited
- Add a caddy reverse proxy
- Add a landing page
- Connect fork-observer
- Connect grafana (thanks @m3dwards )
- Docs
- Update tests
IMO we should be using helm charts to deploy everything, unless we have a specific reason why it can't be done via helm. The manifests folder is really just a leftover and should be deleted once logging has been migrated to a helm chart, so I don't think we should be adding more to it. One of the goals of using helm was to use the python K8s API less, and to get rid of all of the k8s resource yaml files in the repo in favour of using helm charts. To me, this feels like a regression back to what we were doing before and reintroduces some of the old risks, e.g., multiple ways of doing things, difficult to manage config, hardcoded things in different places, etc. |
Great, that’s what I though too |
2022c97
to
917ecd3
Compare
TODO:
|
Nice, thanks for going the helm route! looks much better IMO. I have a PR that cleans up the config and puts all the resources / charts / directory paths in one place, could rebase on that, or I rebase on this if it merges first. |
This is quite a cool idea! I like the implementation. Could even have a command I also can access FO but not grafana yet. |
Thanks, really curious to learn more about integrating this into the bitcoincore chart itself when you have time.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsNo conflicts as of last run. |
9ee680a
to
396f87d
Compare
Concept ACK, very cool! |
b09542b
to
5b1c0fd
Compare
started a review, looks good. in the teardown section, there is a work around due to the fact that commanders are not in a helm chart. id prefer we helmify the commander first and then rebase this? should make this PR simpler. this is also the second PR ive looked at that has a work around due to the commanders not being configured/deployed in the same way as everything else. |
Attempted in #550 |
@willcl-ark does Grafana work for you now? If so let's merge? |
I think this needs a rebase too? (On mobile) |
5b1c0fd
to
6656540
Compare
now that #550 is merged, I think all this needs is a rebase and g2g? |
6656540
to
c0d33df
Compare
Reabsed |
Jesus more conflicts since I started the rebase! :'( |
I'm sorry, I feel your pain. If it makes you feel better, I had it from you this week too! |
c0d33df
to
48df0db
Compare
Ok rebased again. The logging test didn't work for me locally, but it's pretty flakey still regarding whether it gets any data for me (usually), so will see what CI says |
src/warnet/graph.py
Outdated
@@ -180,6 +184,7 @@ def inquirer_create_network(project_path: Path): | |||
custom_network_path, | |||
fork_observer, | |||
fork_observer_query_interval, | |||
fork_observer, # This enables caddy whenever fork-observer is enabled |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, now that logging is enabled by default, perhaps caddy must also be enabled by default in this PR @m3dwards ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say yes? if the dashboard is meant to be how a user interacts with logs , then logs: enabled implies caddy:enabled in my mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now I'm thinking about it I think the logic should be if logging / metrics or if fork observer then yes caddy. I'm not sure we need the ability to disable caddy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And technically, logging isn't enabled by default as both logs and metrics are disabled in values.yaml. It's only enabled if metrics or logs are switched to on in your network definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm ok. I see now in 0c4f76c which I need to remove also (didn't spot in the rebase)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, overall looks good. I'm not crazy about all of the code just for port forwarding, and even less excited to see arch specific code like is_windows
but not a blocker for this PR since port forwarding is the best we have right now. I do think this PR is a pretty good example of why we should move to proper ingress, even if it costs more in a k8s environment.
There are a few other nits that I think would be really nice to address if you end up touching this again, mainly around hard coded constants that I feel should either be in constants.py or in the helm chart itself, but not blocking. Will happily re-review if you end up touching this again.
@@ -16,6 +16,9 @@ grafana.ini: | |||
auth: | |||
disable_login_form: true | |||
disable_signout_menu: true | |||
server: | |||
# this is required to use Grafana behind a reverse proxy (caddy) | |||
root_url: "%(protocol)s://%(domain)s:%(http_port)s/grafana/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just for my own understanding, grafana stuff is in manifests/
for legacy reasons, yeah? was surprised its not also being deployed by helm (not a blocker for this PR tho)
|
||
|
||
@click.command() | ||
def dashboard(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
meh on having a command for this. seems easier to just prompt the user in the logs? also this assumes port forwarding, which I don't think will always be the case, so this command wont work if we move to having proper ingress. lastly, id assume this webbrowser thing will end up failing for some weird reason on someone's computer (cough cough windows).
|
||
cmd = f"{HELM_COMMAND} {name} {CADDY_CHART} --namespace {namespace}" | ||
if debug: | ||
cmd += " --debug" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
src/warnet/deploy.py
Outdated
namespace = "warnet-logging" | ||
name = "caddy" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"warnet-logging" should be a constant in constants.py
imo, and name
should definitely be coming from the helm chart and not hardcoded here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is modified from the fork-observer code which shoud also be updated.
Moved the constant, but getting the component name from the network file is not currently possible as this exists as a key only (so I would just be hardcoding the key here, named "caddy").
src/warnet/deploy.py
Outdated
@@ -99,7 +128,8 @@ def deploy_fork_observer(directory: Path, debug: bool): | |||
if not network_file.get("fork_observer", {}).get("enabled", False): | |||
return | |||
|
|||
namespace = get_default_namespace() | |||
default_namespace = get_default_namespace() | |||
namespace = "warnet-logging" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment regarding constants.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also done
def is_windows(): | ||
return sys.platform.startswith("win") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't need to be addressed in this PR , but this is code smell to me and indicates we really should stop doing port forwarding in favour of ingress (see #529)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think ingress can be its own PR
@@ -115,3 +115,21 @@ def get_default_namespace() -> str: | |||
command = "kubectl config view --minify -o jsonpath='{..namespace}'" | |||
kubectl_namespace = run_command(command) | |||
return kubectl_namespace if kubectl_namespace else DEFAULT_NAMESPACE | |||
|
|||
|
|||
def wait_for_caddy_ready(name, namespace, timeout=300): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this also feels a bit smelly to me, as this is what helm is supposed to be managing for us. I didn't see where this is being used, but im guessing it's for the port forwarding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes waiting for caddy to be ready. This is a k8s thing not helm? I can't concieve of any other way you'd do this for the port forward...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, sorry if my comment was unclear, more saying this wait_for_caddy
function seems specific to port forwarding, so we wouldn't need it if we weren't using port forwarding.
48df0db
to
20b97a0
Compare
5c7b225
to
13f14c3
Compare
will conflict with #585 but we can rebase whichever (add docs!) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Will has rebased this half a dozen times so I think it's only fair to merge this one. |