release the v1 API

[neolit123]

this is a tracking issue to collect ideas for changes from v1beta4->v1.
there is no planned release for v1 yet.

[SataQiu]

Structured ExtraArgs support setting merge policy, for example append or overwrite? Ref #3173

// Arg represents an argument with a name and a value.
type Arg struct {
	Name  string `json:"name"`
	Value string `json:"value"`
        MergePolicy string `json:"mergePolicy"`
}

[neolit123]

Structured ExtraArgs support setting merge policy, for example append or overwrite? Ref #3173

in that ticket it seemed that the issue is the order is not preserved, which is something k8s component don't support, regardless. we do sort our extra args. also extra args do override the default value, which is desired in most cases.

MergePolicy string json:"mergePolicy"

do you have an example what you have in mind?

[SataQiu]

Emm, no more input. It just feels like the current implementation is flawed, and it doesn't make sense to specify some flags more than once, but should be merged into one. Think of it as an optimization. Currently, only patch can be used as a workaround.

[neolit123]

if kubeadm by default has this flag, which btw is a flag that can be passed multiple times to apiserver
-tls-sni-cert-key=foo

the user can pass multiple extraargs
-tls-sni-cert-key=bar
-tls-sni-cert-key=baz

the foo one was removed and the result will be:
-tls-sni-cert-key=bar
-tls-sni-cert-key=baz

• default flag was removed
• we correctly added the user flags multiple times

if the user passed a flag multiple times but only wanted to pass it one time, it's their issue to resolve.
i could still be missing a use case, but seems to me the implementation works fine.

[SataQiu]

if the user passed a flag multiple times but only wanted to pass it one time, it's their issue to resolve. i could still be missing a use case, but seems to me the implementation works fine.

Thanks @neolit123 Sounds reasonable, maybe it should be handled by the users themselves.

[pacoxu]

We can be more cautious and conservative with the release plan of v1.

this is a tracking issue to collect ideas for changes from v1beta4->v1.

Should we include CAPI or other consumers to get more feedback?

[neolit123]

We can be more cautious and conservative with the release plan of v1.

this is a tracking issue to collect ideas for changes from v1beta4->v1.

Should we include CAPI or other consumers to get more feedback?

i have not heard any feature requests offline.
the thread here is open for conversations.

[neolit123]

one topic: if we are going to follow the principle of keeping the same v1 version and adding features to it without version iteration, i think it might be worth exploring a mechanism to make it easy for the user to understand which 'subversion' of v1 that is, and what versions of kubeadm support it and which versions of kubeadm will throw a warning for unknown fields.