k0s icon indicating copy to clipboard operation
k0s copied to clipboard

extraArgs is a dictionary

Open mxrss2 opened this issue 1 year ago • 15 comments

Before creating an issue, make sure you've checked the following:

  • [X] You are running the latest released version of k0s
  • [X] Make sure you've searched for existing issues, both open and closed
  • [X] Make sure you've searched for PRs too, a fix might've been merged already
  • [X] You're looking at docs for the released version, "main" branch docs are usually ahead of released versions.

Platform

Linux 5.15.0-92-generic #102-Ubuntu SMP Wed Jan 10 09:33:48 UTC 2024 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Version

v1.28.5+k0s.0

Sysinfo

`k0s sysinfo`
Machine ID: "fd7a81e4083cbd180875b2e3c1156717f7e016f6406efc4460fead22a9875783" (from machine) (pass)
Total memory: 3.7 GiB (pass)
Disk space available for /var/lib/k0s: 14.1 GiB (pass)
Name resolution: localhost: [127.0.0.1] (pass)
Operating system: Linux (pass)
  Linux kernel release: 5.15.0-92-generic (pass)
  Max. file descriptors per process: current: 1048576 / max: 1048576 (pass)
  AppArmor: active (pass)
  Executable in PATH: modprobe: /usr/sbin/modprobe (pass)
  Executable in PATH: mount: /usr/bin/mount (pass)
  Executable in PATH: umount: /usr/bin/umount (pass)
  /proc file system: mounted (0x9fa0) (pass)
  Control Groups: version 2 (pass)
    cgroup controller "cpu": available (pass)
    cgroup controller "cpuacct": available (via cpu in version 2) (pass)
    cgroup controller "cpuset": available (pass)
    cgroup controller "memory": available (pass)
    cgroup controller "devices": available (assumed) (pass)
    cgroup controller "freezer": available (assumed) (pass)
    cgroup controller "pids": available (pass)
    cgroup controller "hugetlb": available (pass)
    cgroup controller "blkio": available (via io in version 2) (pass)
  CONFIG_CGROUPS: Control Group support: built-in (pass)
    CONFIG_CGROUP_FREEZER: Freezer cgroup subsystem: built-in (pass)
    CONFIG_CGROUP_PIDS: PIDs cgroup subsystem: built-in (pass)
    CONFIG_CGROUP_DEVICE: Device controller for cgroups: built-in (pass)
    CONFIG_CPUSETS: Cpuset support: built-in (pass)
    CONFIG_CGROUP_CPUACCT: Simple CPU accounting cgroup subsystem: built-in (pass)
    CONFIG_MEMCG: Memory Resource Controller for Control Groups: built-in (pass)
    CONFIG_CGROUP_HUGETLB: HugeTLB Resource Controller for Control Groups: built-in (pass)
    CONFIG_CGROUP_SCHED: Group CPU scheduler: built-in (pass)
      CONFIG_FAIR_GROUP_SCHED: Group scheduling for SCHED_OTHER: built-in (pass)
        CONFIG_CFS_BANDWIDTH: CPU bandwidth provisioning for FAIR_GROUP_SCHED: built-in (pass)
    CONFIG_BLK_CGROUP: Block IO controller: built-in (pass)
  CONFIG_NAMESPACES: Namespaces support: built-in (pass)
    CONFIG_UTS_NS: UTS namespace: built-in (pass)
    CONFIG_IPC_NS: IPC namespace: built-in (pass)
    CONFIG_PID_NS: PID namespace: built-in (pass)
    CONFIG_NET_NS: Network namespace: built-in (pass)
  CONFIG_NET: Networking support: built-in (pass)
    CONFIG_INET: TCP/IP networking: built-in (pass)
      CONFIG_IPV6: The IPv6 protocol: built-in (pass)
    CONFIG_NETFILTER: Network packet filtering framework (Netfilter): built-in (pass)
      CONFIG_NETFILTER_ADVANCED: Advanced netfilter configuration: built-in (pass)
      CONFIG_NF_CONNTRACK: Netfilter connection tracking support: module (pass)
      CONFIG_NETFILTER_XTABLES: Netfilter Xtables support: module (pass)
        CONFIG_NETFILTER_XT_TARGET_REDIRECT: REDIRECT target support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_COMMENT: "comment" match support: module (pass)
        CONFIG_NETFILTER_XT_MARK: nfmark target and match support: module (pass)
        CONFIG_NETFILTER_XT_SET: set target and match support: module (pass)
        CONFIG_NETFILTER_XT_TARGET_MASQUERADE: MASQUERADE target support: module (pass)
        CONFIG_NETFILTER_XT_NAT: "SNAT and DNAT" targets support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: "addrtype" address type match support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_CONNTRACK: "conntrack" connection tracking match support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_MULTIPORT: "multiport" Multiple port match support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_RECENT: "recent" match support: module (pass)
        CONFIG_NETFILTER_XT_MATCH_STATISTIC: "statistic" match support: module (pass)
      CONFIG_NETFILTER_NETLINK: module (pass)
      CONFIG_NF_NAT: module (pass)
      CONFIG_IP_SET: IP set support: module (pass)
        CONFIG_IP_SET_HASH_IP: hash:ip set support: module (pass)
        CONFIG_IP_SET_HASH_NET: hash:net set support: module (pass)
      CONFIG_IP_VS: IP virtual server support: module (pass)
        CONFIG_IP_VS_NFCT: Netfilter connection tracking: built-in (pass)
        CONFIG_IP_VS_SH: Source hashing scheduling: module (pass)
        CONFIG_IP_VS_RR: Round-robin scheduling: module (pass)
        CONFIG_IP_VS_WRR: Weighted round-robin scheduling: module (pass)
      CONFIG_NF_CONNTRACK_IPV4: IPv4 connetion tracking support (required for NAT): unknown (warning)
      CONFIG_NF_REJECT_IPV4: IPv4 packet rejection: module (pass)
      CONFIG_NF_NAT_IPV4: IPv4 NAT: unknown (warning)
      CONFIG_IP_NF_IPTABLES: IP tables support: module (pass)
        CONFIG_IP_NF_FILTER: Packet filtering: module (pass)
          CONFIG_IP_NF_TARGET_REJECT: REJECT target support: module (pass)
        CONFIG_IP_NF_NAT: iptables NAT support: module (pass)
        CONFIG_IP_NF_MANGLE: Packet mangling: module (pass)
      CONFIG_NF_DEFRAG_IPV4: module (pass)
      CONFIG_NF_CONNTRACK_IPV6: IPv6 connetion tracking support (required for NAT): unknown (warning)
      CONFIG_NF_NAT_IPV6: IPv6 NAT: unknown (warning)
      CONFIG_IP6_NF_IPTABLES: IP6 tables support: module (pass)
        CONFIG_IP6_NF_FILTER: Packet filtering: module (pass)
        CONFIG_IP6_NF_MANGLE: Packet mangling: module (pass)
        CONFIG_IP6_NF_NAT: ip6tables NAT support: module (pass)
      CONFIG_NF_DEFRAG_IPV6: module (pass)
    CONFIG_BRIDGE: 802.1d Ethernet Bridging: module (pass)
      CONFIG_LLC: module (pass)
      CONFIG_STP: module (pass)
  CONFIG_EXT4_FS: The Extended 4 (ext4) filesystem: built-in (pass)
  CONFIG_PROC_FS: /proc file system support: built-in (pass)

What happened?

So i get the reasoning behind making this a dictionary but this doesnt seem to work with the way Kube does it..

Some flags can be specified multiple times and I can not find a way to specify this flag multiple times. I tried adding it in a second time and k0sctl will complain because it fails validation. I would be happy to work arround this but to be honest I am having a hard time figuring out where the job for the kube-api is in my linux dristro.

--service-account-issuer

You can specify it once but the service.kubernetes.local seems to get overriden which is necessary for SA accounts not in the federated provider.

Steps to reproduce

k0s:
  #   config:
  #     apiVersion: k0s.k0sproject.io/v1beta1
  #     kind: ClusterConfig
  #     metadata:
  #       name: k0s
  #     spec:
  #       api:
  #         extraArgs:
  #           service-account-issuer: https://some-issuer


--service-account-issuer strings
--
  | Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted.


Kube-Api Docs]

Expected behavior

You can't set the servicer.kubernets.local to be in there is well as the ISS scope.

Actual behavior

No response

Screenshots and logs

No response

Additional context

No response

mxrss2 avatar Jan 28 '24 22:01 mxrss2

Maybe it could be changed from map[string]string to map[string]any 🤔

This:

	for name, value := range args {
		apiServerArgs = append(apiServerArgs, fmt.Sprintf("--%s=%s", name, value))
	}

would be changed to:

for name, value := range args {
	switch v := value.(type) {
	case string:
		apiServerArgs = append(apiServerArgs, fmt.Sprintf("--%s=%s", name, v))
	case []string:
		for _, str := range v {
			apiServerArgs = append(apiServerArgs, fmt.Sprintf("--%s=%s", name, str))
		}
	default:
		apiServerArgs = append(apiServerArgs, fmt.Sprintf("--%s=%v", name, v))
	}
}

Then you could have:

          extraArgs:
            service-account-issuer: 
              - https://some-issuer
              - https://some-other-issuer

and it would become --service-account-issuer=https://some-issuer --service-account-issuer=https://some-other-issuer.

But after taking a quick look at the code, I think it may be possible to work around this by using:

          extraArgs:
            service-account-issuer: "https://some-issuer --service-account-issuer=https://some-other-issuer"

kke avatar Jan 29 '24 07:01 kke

@kke thank you so much i didnt even think about doing this -- this is a fantastic solution!

          extraArgs:
            service-account-issuer: 
              - https://some-issuer
              - https://some-other-issuer

Funny enough i tried the above :) Maybe in a future version 👍

mxrss2 avatar Jan 29 '24 19:01 mxrss2

service-account-issuer: "https://some-issuer --service-account-issuer=https://some-other-issuer" this worked? 😮

kke avatar Jan 30 '24 07:01 kke

Maybe this should be kept open and solved properly.

kke avatar Jan 30 '24 07:01 kke

Hmm, not 100% sure, but iirc strings type args can be given as comma separated value. So in this case you should be able to give it comma separated value in yaml dictionary. I.e something like:

extraArgs:
  service-account-issuer: "https://some-issuer,https://some-other-issuer"

jnummelin avatar Jan 30 '24 14:01 jnummelin

		fs.StringArrayVar(&o.ServiceAccounts.Issuers, "service-account-issuer", o.ServiceAccounts.Issuers, ""+
// StringArrayVar defines a string flag with specified name, default value, and usage string.
// The argument p points to a []string variable in which to store the values of the multiple flags.
// The value of each argument will not try to be separated by comma. Use a StringSlice for that.
func (f *FlagSet) StringArrayVar(p *[]string, name string, value []string, usage string) {

will not try to be separated by comma

kke avatar Jan 31 '24 08:01 kke

service-account-issuer: "https://some-issuer --service-account-issuer=https://some-other-issuer" this worked? 😮

Unfortunately i did not test it -- i assumed it did since it seemed clever -- I appologize forgetting back so late and thank you for the info. But it seems that only certain flags in the Kubeapi support multiple flags so should the dictionary be strongly typed?

mxrss2 avatar Feb 06 '24 21:02 mxrss2

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Mar 08 '24 23:03 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Apr 10 '24 23:04 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar May 11 '24 23:05 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Jun 11 '24 23:06 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Jul 12 '24 23:07 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Aug 12 '24 23:08 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Sep 20 '24 23:09 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Oct 21 '24 23:10 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Nov 21 '24 23:11 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Dec 26 '24 23:12 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Jan 29 '25 23:01 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Mar 01 '25 23:03 github-actions[bot]

The issue is marked as stale since no activity has been recorded in 30 days

github-actions[bot] avatar Apr 20 '25 23:04 github-actions[bot]

a relevant issue here I suppose https://github.com/k0sproject/k0s/issues/5714 also, this bug is relevant a bit also with regards to "unary" flags - if I want to pass a flag that has no value and is a "true/false" switch, I also cannot do it easily

aglarendil avatar May 23 '25 10:05 aglarendil

I don't think there's a way in how we could improve extraArgs in a non-breaking way. However, I think we could just add another alternative field, say "rawArgs", that doesn't have the same limitations. We should probably align on how this should look like, and how it plays along with k0s-generated defaults.

As a starting point for a discussion:

  • It needs to be an array, because order matters.
  • It shouldn't prefix any dashes - let users take care of this.

Could look like this:

rawArgs:
- --extra
- args
- --go=here
- -?

Not sure what we should do with the k0s-generated args. Lots of questions here:

  • Should we prepend them, append them, should we try to parse the raw args and do some semantic smarts?
  • How would that interact with extraArgs, should they be mutually exclusive? (If yes, then we definitely need to try to parse rawArgs, I think)
  • Maybe we can instruct folks in the docs to prefer and use extraArgs whenever they can, and only fallback to rawArgs when there's no way of doing it via extraArgs?
  • Maybe we need a more complex way of specifying things than a bare list of strings? Some ordering hints? Some semantic hints?

twz123 avatar Jun 05 '25 10:06 twz123

does ordering actually matter here? I think what should be allowed then is that a user just specifies everything in rawargs if needed. otherways, they are just prepended/appended to the ones generated by k0s. So far it should I think suffice until there is config-v2 version with all the bells and whistles. theoretically, we could also parse those raw args and deserialize them into "configargs" objects, but it is not clear if it can be done right now. welp, now I have an idea: let a user specify a go(sprig?) template for raw args. this go template then will be evaluated with k0s generated args as context and that's it, user can do what ever they want, otherwise, the default template is: {{ range $k,$v := k0s.args }} {{k}={{v}} {{end}}

aglarendil avatar Jun 05 '25 10:06 aglarendil

the variant with

service-account-issuer: "https://some-issuer --service-account-issuer=https://some-other-issuer" this worked?

will not work as it will in fact not be an array of strings and the process will get "https://some-issuer --service-account-issuer=https://some-other-issuer" as a complete string, which simply includes a space, nothing else.

a comma separated might work, though. testing it right now

aglarendil avatar Jun 26 '25 15:06 aglarendil

It is possible to fix in json/yaml-api backward compatible way. Not in go-api compatible way, not sure about the crd compatibility, maybe that is a showstopper. Breaking go-compatibility is not a huge issue in my opinion as k0s is not extensively used as a go module and if it is, it's not a big deal to change a line in your code when updating the dependency.

This would require just changing the type and either writing a custom unmarshal function or add a type-switch to where the value is used.

New format config of course would not work with old k0s but old and new format config would work with new k0s.

kke avatar Jun 27 '25 12:06 kke

after testing we have that there are 2 types of string...var as you rightly mentioned - stringslice and stringarray. stringslice has almost 99% of usage, however some flags for example for kube api are stringarray, like those oidc options. can we add something like a "type-hint" within yaml, maybe a "!multiflag" or smth like this, which will unmarshal it into a list with of strings with the same flag?

aglarendil avatar Jul 04 '25 10:07 aglarendil

Maybe what @kke proposed here might work in backward compatible way. Yes, we'd need to also add validation that the value is either a string or []string, but other than that it might just work.

jnummelin avatar Jul 31 '25 11:07 jnummelin