draft: add support for resource watching, and websocket output

[jasonmadigan]

Started working on #111

But then ended up straying into: #110 as well

Summary:

• Added a --watch flag that setups a watcher for a topology ConfigMap
• Added a --ws flag that sets up a local WebSocket server to publish initial topology (and subsequent updates)
• Renamed --output / -o to --svg / -s (made more sense in my head, output seemed vague?)
• Can use combos of --ws / --svg / --dot. If these are combined with --watch, updates are watched for and the SVG / DOT files are updated until sigint. Note: --watch becomes implicit if using --ws, as starting a WS to flush just once response seemed a bit silly.

Verifying:

Checkout locally, and go build.

Example commands:

./kuadrantctl topology --svg topology.svg --watch # SVG that updates on topology changes
./kuadrantctl topology --svg topology.svg # Just give me a one and done SVG
./kuadrantctl topology --ws --svg topology.svg --dot topology.dot # Give me everything, SVG, DOTfile + WS (implicit watch)
./kuadrantctl topology --ws  # WebSocket only (implicit --watch)

TODO:

• make WS listening port + bind interface configurable
• Narrow configmap watching scope w/ predicates!
• - [ ] Add --web to start a web-server to serve up a simple web page to be fed by the WebSocket, based on https://github.com/Kuadrant/react-policy-topology

[jasonmadigan]

@eguzki spent a little time on this today, and learned some stuff about goroutines. Would appreciate your thoughts (not done yet).

[jasonmadigan]

early draft of this working with the web ui: Kuadrant/react-policy-topology#7

next: add the --web flag.

At some point, we'll update react-policy-topology to use PF and work more like the console plugin's topology view

[jasonmadigan]

Wondering about options to run a web-app container:

• use github.com/docker/docker/client etc to interact with docker. One issue: want this to work with podman too. I know podman has a docker-compatible restful API, but I'm not 100% sure if this works OOTB.
• shell out to whatever runtime is available. Easy, but lots of messiness to deal with that I don't think really belongs in kuadrantctl
• find a nice golang abstraction regardless container runtimes - this would be ideal

[eguzki]

First of all, loving this idea.

Let me discuss the implementation at high level with few questions.

Have you considered running the web server from within another goroutine that is listening to some channel for updates? The service would serve a react application that would open websockets locally waiting for topology updates. Hopefully this makes some sense.

The term websocket is an implementation detail IMO. The user only needs to know that the tool can display the topology in a SVG viewer (whatever the OS has a default viewer for .svg files) or run a local webserver and use your browser to display the topology.

We can always go with docker approach, but that looks like heavier approach, starting with the user is required to have docker installed.

Last, the code looks good and by no means I am asking for a big refactor. At the same time, I would like to say that there is room for improvement and have more encapsulated code. I see like two main functionalities, mutually exclusive, that can be encapsulated separately. One is when the user wants to display the topology using SVG viewer and the other one is running some local server (again websockets is the implementation detail for me) and display using the web browser.

[eguzki]

nice! allows to override the port in case the user is running something else locally in the same port.

[eguzki]

Turning kuadrantctl topology into a k8s controller :) Nice!

[eguzki]

if the topology is not found, that is a known error you can check and exit without any error. Returning an error would make the controller to retry

[eguzki]

nitpick: this is being defined by the predicate. I would just panic so, if for some reason, the runtime goes through that path, the tool is very clear that this is unexpected.