Skip to content
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

Feature: neat clusterip of service #44

Open
iamyeka opened this issue Sep 23, 2020 · 2 comments
Open

Feature: neat clusterip of service #44

iamyeka opened this issue Sep 23, 2020 · 2 comments

Comments

@iamyeka
Copy link

iamyeka commented Sep 23, 2020

When i use the command kubectl get svc kubernetes -o yaml | kubectl-neat to get the neat output of the kubernetes service, the clusterIP is not removed. In result of that, when i apply the output to a new k8s cluster, it turns out the apply cannot be executed successfully for the reason of different ServiceCIDR.
So, neating clusterip of service, is that reasonable?

@itaysk
Copy link
Owner

itaysk commented Sep 24, 2020

Thanks for taking the time to open an issue and a pull request.
I am unsure about this. If the goal of this plugin is to "export" resources so that they can be imported, then yes this PR is welcome, but if the goal is to just improve legibility without interfering with the data, then this is out of scope. Maybe for cases like this we might need another mode (--export?) that takes a more aggressive approach, but I'd like take anther couple of days do consider this.
If there are any other arguments or opinions to share about this feature, we can discuss it here

@iamyeka
Copy link
Author

iamyeka commented Sep 28, 2020

Export mode would be a good choice. For me, kubectl -o wide|custom-columns=... is useful enough with the Table format compared to yaml/json format in daily work. But when it comes to import resources to another cluster, i would use kubectl-neat definitely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants