-
Notifications
You must be signed in to change notification settings - Fork 290
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
egctl: add version
command
#914
Conversation
Can you sparate the design docs into issues in case we can better track it or make contributors/maintainers can help implement it? https://github.com/envoyproxy/gateway/blob/main/docs/latest/design/egctl.md @zirain |
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #914 +/- ##
==========================================
+ Coverage 64.45% 64.48% +0.03%
==========================================
Files 67 67
Lines 8738 8738
==========================================
+ Hits 5632 5635 +3
+ Misses 2733 2730 -3
Partials 373 373
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
internal/cmd/egctl/version.go
Outdated
options.AddKubeConfigFlags(flags) | ||
|
||
versionCommand.PersistentFlags().StringVarP(&output, "output", "o", yamlOutput, "One of 'yaml' or 'json'") | ||
versionCommand.PersistentFlags().StringVar(&egContainerName, "eg-container-name", "envoy-gateway", "Name of the Envoy Gateway container") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't expect the EG container name to change so I'm not sure why the container name needs to be exposed to a user. However, I can see EG being run in a different ns than envoy-gateway-system
and expose the ns to the user while defaulting to "envoy-gateway-system".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
version
will search all namespace, expect vendors may use EG multi-tenancy with custom container name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not following your point here about the EG container name. For multitenancy, a user would install EG in different namespaces with each EG using a different controllerName
. A user would then create a GatewayClass per EG and one or more Gateways that reference the GatewayClass. By default, egctl should expect EG in the envoy-gateway-system
namespace with the Deployment name of envoy-gateway
. If egctl needs to communicate with an EG in a different namespace, a flag such as --namespace
should be surfaced. For security purposes, we should avoid providing egctl access across all namespaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me remove this part first.
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
output of running
|
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
I just tested egctl and it's showing the incorrect client version. Maybe this PR needs to be rebased?
In the future, EG could be running multiple replicas. In this case, which pod name will be displayed? It might be better to surface the deployment name instead. |
Signed-off-by: hejianpeng <hejianpeng2@huawei.com>
after rebasing from main, it's correct now. |
@zirain thanks for rebasing. I have confirmed that the client/server versions now match. As a follow-on to #914 (comment), EG can run multiple replicas in the future. In this case, which pod name will be displayed? I think it's better to surface the EG deployment name instead of the pod name. Thoughts? |
for now, envoy pod will displayed. |
Why display the Pod name instead of the Deployment name? |
if you look at the implement, |
Yes, I understand the implementation. I just don't understand the purpose of displaying the EG pod name instead of the deployment name. I'm fine with resolving this in the future when EG supports multiple replicas. |
@zirain I can approve after you resolve the merge conflicts. |
I prefer deployment name too, but let us get this in first. We can make it later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @zirain !
xref: #915