Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

@mulatinho: GitHub didn't allow me to request PR reviews from the following users: royalsflush.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

Welcome @mulatinho!

It looks like this is your first PR to kubernetes/kubernetes 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kubernetes has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @mulatinho. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/cc @aojea
/assign @aojea

hope it helps and makes sense for you :-)

/lgtm

(Be mindful you still need approval)

@royalsflush: changing LGTM is restricted to collaborators

/hold

thanks for the contribution, but refactors need to be adding clear value, replacing hardcoded values by a common variable is, but I want to keep them per test.

Use different commits for changes and different files, do not mix unrelated things in the same commit, do not change things like comma separated arguments , ...

@aojea I reviewed all changes and I think now its bringing value as you requested, I fixed the exposition of variables, formatted the output lines and seems good to me, consistent. waiting for your feedback, hope it get approved :)

/kind cleanup

thanks for the effort but now you have some commits that go back and forth, you add some variables and then you remove then, can you have a clean history with the actual changes we want to merge?

@aojea here it is , two commits, one per single file, with all changes to track in each commit :-) thanks

/assign @danwinship
/assign @andrewsykim

/test pull-kubernetes-e2e-kind

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mulatinho
Once this PR has been reviewed and has the lgtm label, please ask for approval from andrewsykim. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

/test pull-kubernetes-e2e-kind

thanks brother, I think it will need approval first ./cc @aroradaman

/ok-to-test