systemd specs should be in-repo

[BenTheElder]

What happened:

#87585 (review)

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• OS (e.g: cat /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

/assign @justaugustus

[brenix]

I currently maintain the Archlinux AUR packages for kubeadm and kubelet, which relied on the default kubelet.service and kubeadm drop-in in the repo. It would be preferred to keep these in-repo so that other distributions can source the upstream default, rather than having to create it out of band. Thanks!

[neolit123]

rather than having to create it out of band

currently these come from:
https://github.com/kubernetes/release/tree/master/cmd/kubepkg/templates/latest/deb/kubeadm

but matching the specs to k8s tags/releases is probably better.

[dims]

/sig release

[BenTheElder]

another reason these should be versioned in the main repo kubernetes/release#1352

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[BenTheElder]

this is still true, for anyone not using the debs/rpms you either have to reinvent these or do quite some digging to turn up the upstream ones. consumers are not likely to be aware of kubernetes/release to begin with.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.

[BenTheElder]

/reopen
/remove-lifecycle rotten

[k8s-ci-robot]

@BenTheElder: Reopened this issue.

In response to this:

/reopen
/remove-lifecycle rotten

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.

[k8s-ci-robot]

@BenTheElder: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[BenTheElder]

At the very least we should probably leave a more obvious trail to find them. That might be less effort but still somewhat helpful.

I still think we want them versioned with the binaries for other reasons though.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[BenTheElder]

I attempted to discuss this but I've been blocked on waiting for the new world of Kubernetes debian/rpm packaging to exist which has been in limbo for at least a year now, I really don't have the time / energy for this right now.

I still think it is wrong to have:

1. specs that are not versioned with kubernetes
   • this is blocking fixing the kubeadm crash looping kubelet experience
2. specs that are not easily found from the kubernetes project

[BenTheElder]

Kubelet service spec also doesn't have KillMode=process set when it probably should, but again that would technically be a breaking change and these files are unversioned.

Ever cluster tool inside and outside the project is just hard-forking the systemd files to fix things like this.

[tao12345666333]

Yes. Setting this option makes sense. And if it is version controlled, users will know about the change before upgrading.