add --watch support for resource watching

[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
• 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

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 --watch --svg topology.svg --dot topology.dot # Give me everything, SVG, DOTfile + WS (implicit watch)
./kuadrantctl topology --watch  --dot topology.dot # WebSocket only (implicit --watch)

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

[jasonmadigan]

Couple of changes TODO (will find time this week):

• remove the --ws + websocket serving stuff
• keep the watch stuff, still useful for dynamic svg/dotfile updates.
• Local users: open the DOTfile in something like vscode or whatever, and with --watch, it'll dynamically update

we'll separately look at a deployable service for kube to do similar to the WS stuff (Basically: have an installable service for a topology service on kube/podman/docker)

[jasonmadigan]

@eguzki think this is ready for another pass, have paired this back to just adding --watch for the time being