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

kg: add new handler for rendering the topology graph via the metrics webserver #214

Merged
merged 20 commits into from
Aug 18, 2021

Conversation

stv0g
Copy link
Contributor

@stv0g stv0g commented Jul 15, 2021

Closes #23

@squat , @leonnicolas: I am not too happy about the code-duplication for creating a mesh.Topology instance.

At the same time, I am lacking the deeper insight into Kilos code-base to understand where we could put this code.
I was thinking about a function mesh.Backend.Topology() or mesh.Mesh.Topology().
I guess the main question would be then weather we want to query the current topology directly from the backend or if we take the current state from the mesh object?

for _, n := range ns {
if n.Ready() {
nodes[n.Name] = n
hostname = n.Name
Copy link
Owner

Choose a reason for hiding this comment

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

We always know the name of the node running this process, since it's provided as a command line argument to kg. I would saw we should use this value always. It will also help future-proof the code I think

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done :) I now pass the hostname and the Kilo subnet to the handler.

However, wouldnt it be nicer if we export those fields from the Mesh and only pass the mesh to the handler?

Copy link
Owner

Choose a reason for hiding this comment

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

yes, something in this direction could be nice. Maybe we want the mesh to actually provide a method for getting ready nodes and peers? We need this logic in a bunch of places, like kgctl, so it could be nice to reuse

cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
Copy link
Owner

@squat squat left a comment

Choose a reason for hiding this comment

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

This is a nice feature! Thanks for working on this, @stv0g!!!
Do you think you could also add an e2e test that at a minimum validates that the response contains some SVG XML? This would be sufficient IMO. Let me know if you need help here, or we can try to tackle it in a follow-up.

@stv0g
Copy link
Contributor Author

stv0g commented Jul 16, 2021

Hi @squat,

thanks for the review :) I think i've addressed most of them.
I just dont like how I need to pass hostname and subnet in addition to the mesh to the graph handler since they are already members of the mesh type itself.

But it seems like Mesh does not really export anything. So I am not too sure how you want to handle this.

I also gave the e2e tests a try in my last commit.

Cheers,
Steffen

e2e/handlers.sh Outdated Show resolved Hide resolved
e2e/handlers.sh Outdated Show resolved Hide resolved
e2e/handlers.sh Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
cmd/kg/handlers.go Outdated Show resolved Hide resolved
e2e/handlers.sh Outdated Show resolved Hide resolved
e2e/handlers.sh Outdated Show resolved Hide resolved
@leonnicolas
Copy link
Collaborator

When I generate a png with curl '<Kilo Pod IPr>:1107/graph&format=png' -o g.png', the circles look as expected, but all text is not rendered correctly. Looks like a formatting issue or the font is not known.
When I generate the png with curl '<Kilo Pod IP>:1107/graph&format=dot' | crico -Tpng everything look great.
Do you have a better idea why this is not working?

Co-authored-by: leonnicolas <60091705+leonnicolas@users.noreply.github.com>
@stv0g
Copy link
Contributor Author

stv0g commented Jul 22, 2021

Thanks @leonnicolas for looking into it. I had trouble with my dev environment to properly debug the issues here.

When I generate a png with curl ':1107/graph&format=png' -o g.png', the circles look as expected, but all text is not rendered correctly. Looks like a formatting issue or the font is not known.

Thats due to missing fonts in your containers. The PR includes a change in the Dockerfile to install some standard font:

https://github.com/squat/kilo/pull/214/files#diff-dd2c0eb6ea5cfc6c4bd4eac30934e2d5746747af48fef6da689e85b752f39557

@leonnicolas
Copy link
Collaborator

Thats due to missing fonts in your containers. The PR includes a change in the Dockerfile to install some standard font:

I was building the container images from your branch :(

@leonnicolas
Copy link
Collaborator

g

I checked out your branch and run the e2e test. The svg is fine, but the png looks like this.

Either we fix this, or disable the png (and other formats) options.

Installing font-noto fixed the issue.

@stv0g
Copy link
Contributor Author

stv0g commented Aug 9, 2021

@leonnicolas thanks for investigating. I added font-noto to the Dockerfile

Dockerfile Outdated
@@ -11,7 +11,7 @@ ARG GOARCH
ARG ALPINE_VERSION=v3.12
LABEL maintainer="squat <lserven@gmail.com>"
RUN echo -e "https://alpine.global.ssl.fastly.net/alpine/$ALPINE_VERSION/main\nhttps://alpine.global.ssl.fastly.net/alpine/$ALPINE_VERSION/community" > /etc/apk/repositories && \
apk add --no-cache ipset iptables ip6tables wireguard-tools
apk add --no-cache ipset iptables ip6tables wireguard-tools graphviz font-bitstream-type1 font-noto
Copy link
Owner

Choose a reason for hiding this comment

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

Can we do this without font-bitstream-type1 and just noto? It would be nice to keep the container with just the essentials

This commit leaves Noto as the only font package, as one font package is
sufficient for the container.

Signed-off-by: Lucas Servén Marín <lserven@gmail.com>
@squat
Copy link
Owner

squat commented Aug 18, 2021

I went ahead and added a commit removing the extra font. When testing this with the e2e tests everything works. I'm able to spin up a kind cluster, port forward to a Kilo pod and open http://localhost:1107/graph?format=png in the browser to produce the following image.
image
I think this is ready to be merged!

@leonnicolas
Copy link
Collaborator

leonnicolas commented Aug 18, 2021

See 1b5ad03 for the squashed commits in upstream.

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.

feat issue: Web view of topology graph
3 participants