Network console collector

skupperproject / skupper

Skupper is an implementation of a Virtual Application Network, enabling rich hybrid cloud communication.

http://skupper.io

Apache License 2.0

559 stars 71 forks source link

Network console collector #1517

Open c-kruse opened 2 weeks ago

c-kruse commented 2 weeks ago

Reworks the flow collector such that it can be independently deployed as the network-console-collector.

Simplifies startup - relying on command arguments and a messaging.json config instead of platform-specific environment inference. Minimizes skupper package dependencies.
Removes all authentication concepts from the collector api for now: I did not want to commit to the old configuration interface for them and their implementation does not pass for me.
Adds example deployment configurations

nluaces commented 1 week ago

I think that it is necessary to do also the refactor in images.go and image_utils.go files (at least); in order to provide the information of what image version of the different skupper components is being used by default (or configured by the user through environment variables).

usage: version, manifest

c-kruse commented 1 week ago

I think that it is necessary to do also the refactor in images.go and image_utils.go files (at least); in order to provide the information of what image version of the different skupper components is being used by default (or configured by the user through environment variables).

usage: version, manifest

Thanks! Good catch. Probably ties in a little to a conversation we'd best have sometime coming up: should skupper know about the network console at all? i.e. should this image stick around in the manifest, or should we just remove the flow-collector

nluaces commented 1 week ago

should skupper know about the network console at all? i.e. should this image stick around in the manifest, or should we just remove the flow-collector

Fair enough! In my opinion, maybe it is not that critical for the version command as it is no longer a sidecar of the controller, but maybe it would still be helpful for the manifest -release wise- for traceability.

c-kruse commented 1 week ago

@nluaces @fgiorgetti - a few of your comments are on getting these working with v2. I had written the deployment examples under /resources to run alongside skupper v1 as sort of proof of concepts since v2 is just shy of ready.

For kube sites I believe we just need the skupper-local-client secret replacement to get provisioned, and for non-kube I think we could start looking at some of fernando's ideas once phase 0 is merged.

Thoughts on adding issues to come back and update the examples once those bits get brought in? Otherwise we could park this for a week or so until it could be ran alongside v2.