Add a egctl get <x> --graph command to be able to visualize dependencies between gateway API resources

[haq204]

Description:
An issue that crops up when using the Gateway API is understanding the dependency between resources. For example, When listing a gateway resource, a platform/infrastructure developer wants to know what HTTPRoutes are attached to it or what extensionRef filters are attached to an HTTPRoute.

Introduce a get subcommand with a --graph option that outputs a tree of gateway resources and how they are related. For example, egctl get --graph gateway mygateway could output:

NAME                                                                     CLASS   ADDRESS          PROGRAMMED   AGE
mygateway                                                                eg      9.9.9.9          True         1d
        HTTPRoute/namespace=default;name=route1;hostname=foo.com;age=1d
        HTTPRoute/namespace=default;name=route2;hostname=bar.com;age=1d

The columns are the standard column outputs from kubectl get and subresources also provide the same information from kubectl get deliminated by ; as well as an additional namespace field.

Initially we can start with Gateway Classes, Gateways, & HTTPRoutes, and eventually add support extensionRef filters.

We could also eventually propose adding it to upstream kubectl for Gateway API resources

[zirain]

I think this's a good idea, but not sure if it's part of analysis command?
@arkodg @danehans WDYT?

[arkodg]

@zirain I think analyze is a superset of this command.
this would look more like http://mama.indstate.edu/users/ice/tree/
if there is no edge/link between parent and child resource analyze could flag it as a WARNING

[haq204]

@zirain @arkodg yea I think the get and analyze subcommands serves different but related purposes. the get --graph subcommand gives you the current tree of gateway api resources and their relationships.

analyze is for determining whether there could be a problem in your configuration. For example, you have a gateway not associated with a gateway class. get would just list the gateway resource as is and say this is what is currently deployed. analyze would say: "hey you got this gateway resource that's not linked with any gateway class. We don't know if that's what you intended but we're flagging it as a warning just in case". There's also more obvious things like gateways referencing a gateway class that doesn't exist. analyze can flag that as an obvious error.

[zirain]

get would just list the gateway resource as is and say this is what is currently deployed

egctl get gateway-api gateway <your gateway name> would be better?

for Route:

egctl get gateway-api Route <your route name> WDYT?

[haq204]

would there be other get subcommands beyond get gateway-api? I wouldn't want to add additional subcommands than necessary. I would be open to getting rid of the --graph flag and just make it the default view. Originally I thought of it as something pretty similar to kubectl get but with a --graph flag but something like:

egctl get gateway <my-gateway>

egctl get route <my-route>

could work. If you want a normal resource list, just use kubectl get

Let me know what you think @zirain & @arkodg

[arkodg]

@haq204 the design doc for egctl proposes a subcommand called egctl config (instead of get ) that we can piggyback on.
we can either have egctl config gateway-api which suggests we are fetching this info from the k8s API server or have egctl config envoy-gateway <> which would fetch this info (GAPI resources) from the EG Admin server (which is a TODO)

[haq204]

@arkodg perhaps we can omit the envoy-gateway subcommand and have it just

egctl config gateway <my-gateway>

egctl config route <my-route>`

I'm just thinking in terms of how I would be typing this in the terminal 😆 but I'm not opposed to putting it behind egctl config envoy-gateway as well. That also makes sense to me and would be analogous to envoy-proxy i.e

egctl config envoy-gateway gateway <gateway-name>`

and

egctl config envoy-proxy listener <listener-name>`

My only worry is that it's a lot to type but I guess that's what aliases are for.

[arkodg]

yah agree, its a lot more to type, but it adds consistency to the config cmd, eg and ep aliases can help

[zirain]

IMO, egctl config envoy-gateway gateway <gateway-name> is a good approach.

[haq204]

In the original post I mentioned about potentially upstreaming this to kubectl since we're just dealing with Gateway API resources. Another possible route is to make this a kubectl plugin while we work on getting this built into kubectl. Since this isn't a Envoy Gateway specific thing but every Gateway API implementation would benefit from this.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[arkodg]

linking a cool piece of tech that @michaelvl built out https://github.com/michaelvl/gateway-api-lens that does this !

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[arkodg]

upstream has introduced gwctl and a lot of what this issue is taking about exists there. closing for now