[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: luxas

Associated issue: 50320

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

So you're treading in weird territory here. You're backporting a new feature.

That requires further explanation as to why.

@timothysc I thought we had discussed this a couple of times.
If we decide to not do this, it's fine for me, but my interpretation from the earlier sig calls where this has been discussed was that this is something we want to do for better UX.

So this makes the upgrade from v1.7.4->v1.8 much easier as the user doesn't have to create a configuration file in their own to feed kubeadm upgrade with. Instead this is handled just out of the box, as kubeadm upgrade can just read what the previous config were and can adopt to that.

cc @kubernetes/sig-cluster-lifecycle-pr-reviews
Do we want to enhance the UX in this way with regards to upgrading or should we leave this as-is?

I'm calling it out for the release manager to weigh in.

Dunno what if/any formal policy we have here, also it would be weird in that it would only affect 1.7.x and > vs all of 1.7 .

cc @roberthbailey @jbeda WDYT?

cc @wojtek-t as the branch manager

Just to give the branch manager more context, this isn't fixing a bug, but is improving the future upgrade story for kubeadm-initialized clusters.

Without this cherry-pick, our upgrade directions will look like:

If you initialized your cluster with kubeadm < 1.8, follow steps A to upgrade it.

If you initialized your cluster with kubeadm >= 1.8, follow steps B to upgrade it.

With this cherry-pick, we'll still have the same directions, but with different version boundaries:

If you initialized your cluster with kubeadm < 1.7.4, follow steps A to upgrade it.

If you initialized your cluster with kubeadm >= 1.7.4, follow steps B to upgrade it.

The actual steps in process A are more tedious and error-prone than B, and were a stopgap implementation when process B wasn't ready in time for the 1.7 release. Process B should be a lot friendlier to users and more fool-proof, so this cherry-pick is targeting being able to get users on the B train even earlier than the 1.8 release.

Is that a fair synopsis, @luxas?

I don't think I should be making this decision.
@roberthbailey - WDYT?

You are the branch manager, so you should be making the ultimate decision. :)

@luxas -- you say

this makes the upgrade from v1.7.4->v1.8 much easier

But it doesn't help the upgrade from 1.7.x->1.7.4+ or 1.7.x (x<4) to 1.8.

@roberthbailey - I know that I'm decision maker, but I would like to get your recommendation as you're the SIG lead.

Here's a good thought experiment: If kubeadm was in it's own repository, would we add this change for deploying 1.7 clusters or wait and add it for 1.8 and above? Based on the way that we make changes to GKE, I'm inclined to say the former.

Since this cherry pick is isolated to kubeadm code (which is technically not part of the nucleus even though it's in the main repo) I don't have a problem back porting this change.

OK- I approve the cherrypick.

Can someone please lgtm it?

@timothysc and @pipejakob lgtm'd the original PR so they would be appropriate to take a look here if you want an extra set of eyes.

@luxas - verify failure is a real one. Please fix.

/retest

This is a weird policy thing we should bring up in the meeting. I'm ok if the SIG is ok with it, but it should be more of an exception then the norm.

Agreed; let's discuss this tomorrow

LGTM, based on the original PR. Since we're discussing in the SIG meeting tomorrow, I'll hold off from adding the label now to keep this out of the submit queue.

We decided in the SIG Meeting to not go with this approach for now