Skip to content
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

Merged
merged 12 commits into from
Sep 12, 2024

Conversation

willcl-ark
Copy link
Contributor

@willcl-ark willcl-ark commented Sep 4, 2024

  • Add a caddy reverse proxy
  • Add a landing page
  • Connect fork-observer
  • Connect grafana (thanks @m3dwards )
  • Docs
  • Update tests

@willcl-ark willcl-ark changed the title faster and cleaner teardown unified HTML springboard (NOT a dashboard!) Sep 4, 2024
@josibake
Copy link
Collaborator

josibake commented Sep 5, 2024

Uses the k8s API (it would be much less code to, as I had in my first iteration, to simply apply all *.yaml files in the caddy directory with subprocess). @m3dwards is this something we should also make a chart for like fork observer? I don't really know where the boundary of raw yaml files and charts lies, but this seemed simpler as a first approach

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.

@willcl-ark
Copy link
Contributor Author

Great, that’s what I though too

@willcl-ark
Copy link
Contributor Author

willcl-ark commented Sep 5, 2024

TODO:

  • add auto-port-forward and tear-down
  • docs

@willcl-ark willcl-ark marked this pull request as ready for review September 5, 2024 10:36
@willcl-ark willcl-ark changed the title unified HTML springboard (NOT a dashboard!) unified HTML landing page (NOT a dashboard!) Sep 5, 2024
@josibake
Copy link
Collaborator

josibake commented Sep 5, 2024

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.

@m3dwards
Copy link
Collaborator

m3dwards commented Sep 5, 2024

This is quite a cool idea! I like the implementation.

Could even have a command warnet not-dashboard that opens the webpage for you!

I also can access FO but not grafana yet.

@willcl-ark
Copy link
Contributor Author

This is quite a cool idea! I like the implementation.

Thanks, really curious to learn more about integrating this into the bitcoincore chart itself when you have time.

Could even have a command warnet not-dashboard that opens the webpage for you!

warnet dashboard added in 585295f. Nice idea.

  • fork-observer test updated to now test via the caddy proxy

@256dummy
Copy link

256dummy commented Sep 5, 2024

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

@josibake
Copy link
Collaborator

josibake commented Sep 6, 2024

Concept ACK, very cool!

@willcl-ark willcl-ark force-pushed the caddy-proxy branch 3 times, most recently from b09542b to 5b1c0fd Compare September 7, 2024 13:49
@josibake
Copy link
Collaborator

josibake commented Sep 8, 2024

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.

@willcl-ark
Copy link
Contributor Author

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

@m3dwards
Copy link
Collaborator

m3dwards commented Sep 9, 2024

@willcl-ark does Grafana work for you now? If so let's merge?

@willcl-ark
Copy link
Contributor Author

I think this needs a rebase too? (On mobile)

@josibake
Copy link
Collaborator

now that #550 is merged, I think all this needs is a rebase and g2g?

@willcl-ark
Copy link
Contributor Author

Reabsed

@willcl-ark
Copy link
Contributor Author

Jesus more conflicts since I started the rebase! :'(

@m3dwards
Copy link
Collaborator

m3dwards commented Sep 11, 2024

I'm sorry, I feel your pain.

If it makes you feel better, I had it from you this week too!

@willcl-ark
Copy link
Contributor Author

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

@@ -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
Copy link
Contributor Author

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 ?

Copy link
Collaborator

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.

Copy link
Collaborator

@m3dwards m3dwards Sep 11, 2024

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.

Copy link
Collaborator

@m3dwards m3dwards Sep 11, 2024

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.

Copy link
Contributor Author

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)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

@josibake josibake left a 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/"
Copy link
Collaborator

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():
Copy link
Collaborator

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"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

Comment on lines 103 to 107
namespace = "warnet-logging"
name = "caddy"
Copy link
Collaborator

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.

Copy link
Contributor Author

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").

@@ -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"
Copy link
Collaborator

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also done

Comment on lines +256 to +261
def is_windows():
return sys.platform.startswith("win")
Copy link
Collaborator

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)

Copy link
Contributor Author

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):
Copy link
Collaborator

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?

Copy link
Contributor Author

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...

Copy link
Collaborator

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.

@willcl-ark willcl-ark marked this pull request as ready for review September 11, 2024 18:55
@pinheadmz
Copy link
Contributor

pinheadmz commented Sep 11, 2024

will conflict with #585 but we can rebase whichever (add docs!)

@willcl-ark willcl-ark mentioned this pull request Sep 11, 2024
Copy link
Collaborator

@m3dwards m3dwards left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@m3dwards m3dwards merged commit d4a0190 into bitcoin-dev-project:main Sep 12, 2024
11 checks passed
@m3dwards
Copy link
Collaborator

will conflict with #585 but we can rebase whichever (add docs!)

Will has rebased this half a dozen times so I think it's only fair to merge this one.

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.

5 participants