Changed to use first_kube_control_plane to parse kubeadm_certificate_key

[Xartos]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:

When reordering controlplane nodes in inventory.ini and the first in the list is not the same as the first one when running kubectl get nodes --selector=node-role.kubernetes.io/control-plane -o json you'll get an error:

fatal: [some-name-k8s-control-plane-6]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'kubeadm_certificate_key' is undefined. 'kubeadm_certificate_key' is undefined"}

This is because the variable first_kube_control_plane is ultimately set using kubectl and this is the one that is used to create the certificate.
However the one after is using groups['kube_control_plane'][0] which will depend on what node is first in inventory.ini hence why this error occurs.

This PR changes so the parsing also fetches the certificate from the first_kube_control_plane.

Which issue(s) this PR fixes:

Fixes #10973

Special notes for your reviewer:

All credit to @nvalembois who had this patch in #10973

Does this PR introduce a user-facing change?:

Fix a bug where `kubeadm_certificate_key` was not defined if control plane nodes were not in correct order 

[k8s-ci-robot]

Hi @Xartos. Thanks for your PR.

I'm waiting for a kubernetes-sigs 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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[VannTen]

Hum, if @nvalembois wrote the patch, maybe we should put it as author in the commit ? and I'm not sure how that interacts with the k-sigs CLA stuff ?
@yankay know anything about that ?
/ok-to-test

[Xartos]

Hum, if @nvalembois wrote the patch, maybe we should put it as author in the commit ? and I'm not sure how that interacts with the k-sigs CLA stuff ? @yankay know anything about that ? /ok-to-test

Right, yea if it's easier then @nvalembois is free to create another PR instead of me and I'll close this one. As long as we get the fix then I'm happy

[VannTen]

You could also put Co-Authored-By: Name <email> At the end of the commit message. But I'm not sure the CLA bot take it into consideration though.

[Xartos]

Hmm, can't seem to see any details on what the CLA action looked at now so I can't tell. But let's see if @yankay knows

[VannTen]

I think you need to rebase on master for the CI, this is because of recent CI cleanups.

[VannTen]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: VannTen, Xartos

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [VannTen]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[VannTen]

/cherrypick release-2.27

[k8s-infra-cherrypick-robot]

@VannTen: new pull request created: #12758

In response to this:

/cherrypick release-2.27

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.