config_path in containerd config should be present by default

[janekmichalik]

DESCRIPTION SECTION REMOVED AS IT IS NOT RELEVANT IN THIS CASE

config_path should be added by default in roles/container-engine/containerd/templates/config.toml.j2, as currently it is added only when containerd_insecure_registries is defined, what if I want to configure secure registry? This field won't be added. While running containerd config default > /etc/containerd/config.toml the config_path = "" is present.

With containerd config default > /etc/containerd/config.toml:

    [plugins."io.containerd.grpc.v1.cri".registry]
      config_path = ""

      [plugins."io.containerd.grpc.v1.cri".registry.auths]

      [plugins."io.containerd.grpc.v1.cri".registry.configs]

      [plugins."io.containerd.grpc.v1.cri".registry.headers]

      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]

    [plugins."io.containerd.grpc.v1.cri".x509_key_pair_streaming]
      tls_cert_file = ""
      tls_key_file = ""

With kubespray (default):

    [plugins."io.containerd.grpc.v1.cri".registry]
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
          endpoint = ["https://registry-1.docker.io"]

While installing kubernetes using kubespray, I want to manipulate with containerd config later on. To have one generic behaviour, when config_path field is present in containerd config file. In my case it is all about enabling TLS for internal registry as described in:

• Configure Image Registry
• Registry Configuration

[XDRAGON2002]

Isin't this a duplicate of #9770? A patch for that was already merged.

[oomichi]

Isin't this a duplicate of #9770? A patch for that was already merged.

Yeah, that is a nice point.

@janekmichalik Could you check #9770 and if that works for you please close this issue.

[janekmichalik]

@XDRAGON2002 and @oomichi thx for reply.

I have seen this one, but config_path is not used there by default as containerd_use_config_path: false.

[yankay]

@XDRAGON2002 and @oomichi thx for reply.

I have seen this one, but config_path is not used there by default as containerd_use_config_path: false.

HI @janekmichalik
The original config can be used in the containerd 1.x. and would be removed in containerd 2.0.
We can use the new config_path by containerd_use_config_path: true

[janekmichalik]

@XDRAGON2002 and @oomichi thx for reply.
I have seen this one, but config_path is not used there by default as containerd_use_config_path: false.

HI @janekmichalik The original config can be used in the containerd 1.x. and would be removed in containerd 2.0. We can use the new config_path by containerd_use_config_path: true

Yes, I know it. But imo the default containerd config file (config.toml.j2) should be the same as the original containerd default config without asking for it via containerd_use_config_path: true. If no vars or defaults provided in ansible, kubespray should set config.toml.j2 to look exactly the same as when running containerd config default > /etc/containerd/config.toml.

Currently: default config.toml.j2 != containerd config default > /etc/containerd/config.toml.

[XDRAGON2002]

@XDRAGON2002 and @oomichi thx for reply.
I have seen this one, but config_path is not used there by default as containerd_use_config_path: false.

HI @janekmichalik The original config can be used in the containerd 1.x. and would be removed in containerd 2.0. We can use the new config_path by containerd_use_config_path: true

Yes, I know it. But imo the default containerd config file (config.toml.j2) should be the same as the original containerd default config without asking for it via containerd_use_config_path: true. If no vars or defaults provided in ansible, kubespray should set config.toml.j2 to look exactly the same as when running containerd config default > /etc/containerd/config.toml.

Currently: default config.toml.j2 != containerd config default > /etc/containerd/config.toml.

@yankay @oomichi
I think this might be a reasonable request? Thoughts?

[janekmichalik]

@yankay @oomichi any thoughts?

[yankay]

HI @janekmichalik

Thanks for the suggestion.
I'm not exactly sure about the proposal for the issue.
It does not matter that the default value config.toml is different.

If you like would you please submit a PR the solve it? Thank you very much.

[janekmichalik]

HI @janekmichalik , @XDRAGON2002 .

Thanks for the suggestion.

I have investigated the KOPS , which using the same method as kubespray.

• https://github.com/kubernetes/kops/blob/master/nodeup/pkg/model/containerd.go#L485

So the default value is reasonable in Containerd 1.x .

And I want to support changing it when the Containerd 2.x is released and accepted by Kubernetes. (Only personal opinion)

Thx @yankay for your feedback. IMO as Containerd 2.x is not released yet, shouldn't we focus on existing Containerd 1.x?
Can you share the doc describing how it will behave (as the default value is reasonable in Containerd 1.x .) in containerd for 2.x ?

[yankay]

HI @janekmichalik , @XDRAGON2002 .
Thanks for the suggestion.
I have investigated the KOPS , which using the same method as kubespray.

• https://github.com/kubernetes/kops/blob/master/nodeup/pkg/model/containerd.go#L485

So the default value is reasonable in Containerd 1.x .
And I want to support changing it when the Containerd 2.x is released and accepted by Kubernetes. (Only personal opinion)

Thx @yankay for your feedback. IMO as Containerd 2.x is not released yet, shouldn't we focus on existing Containerd 1.x? Can you share the doc describing how it will behave (as the default value is reasonable in Containerd 1.x .) in containerd for 2.x ?

HI @janekmichalik

I'm sorry that I may not get the point of the issue.

Ref to the #9743 (comment) , The config_path and registry.mirror cannot work together. So the containerd_use_config_path default value is false.

I'm not exactly sure about the proposal for the issue.

If you like would you please submit a PR the solve it? :-)
Thank you very much.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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/test-infra repository.