k0sproject
Drop kardianos/service dependency
We anyways already provide our own templates for system units and thus do not depend that much on the library functionality.
kardianos/service is not really maintained, there's e.g. a bug fix PR opened by myself on June 2023 which has not been merged.
I propose that we drop the whole dependency, use our own templates fully and provide needed wrappers around. We handle much of the same/similar logic in k0sctl/rig side already and thus known what needs to be done.
- Detect init system (done in https://github.com/k0sproject/rig/tree/main/initsystem)
- Write out the template (they are already in go text/template format in k0s sources)
- Implement
k0s startandk0s stop(also implemented in the same files in rig)
The issue is marked as stale since no activity has been recorded in 30 days
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
We had a bug in the current implementation (here is the fix), so let's also add some unit tests to make sure, that the generated services are correct
The issue is marked as stale since no activity has been recorded in 30 days
The issue is marked as stale since no activity has been recorded in 30 days
The issue is marked as stale since no activity has been recorded in 30 days
The issue is marked as stale since no activity has been recorded in 30 days
I see few options:
- "Vendor in" the needed kardianos parts with the obvious notes on original source&licence etc.
- Create a fork of kardianos. I'm not sure how much we'd want to maintain that
- Do everything from scratch
I think the best option is to "vendor in" the needed kardianos bits and go from there.
@k0sproject/k0s-maintainers WDYT?
I'd go for "from scratch". We're probably not interested in maintaining a general purpose service library, so forking wouldn't be sustainable. Inlining the code means that we'd need to address the legal requirements, copyright notices and everything, which has maintenance cost, too.
Doing it from scratch would be the cleanest approach.
Perhaps a middle ground could be to introduce an internal API to interact with init systems, which then delegates to Kardianos service. Then, we could add dinit support (#5765) ourselves in terms of our new internal API, without being forced to do so upstream. We could then port each init system individually until we replace them all and can drop the dependency entirely.
For the record, as far as I can tell we're concerned with:
- systemd
- OpenRC
- The Windows Service API
The issue is marked as stale since no activity has been recorded in 30 days
The issue is marked as stale since no activity has been recorded in 30 days