Does the split of K8up and Wrestic make sense?

[tobru]

K8up and Wrestic go together hand-in-hand. K8up depends on it to actually run the jobs, while Wrestic in theory could be used standalone.

Because of this tight coupling I'd like to question if it really makes sense to treat Wrestic as a separate project / Git repo or if it should be integrated into K8up. Integration would have the following advantages:

• Consistent versioning - same K8up version works best with same Wrestic version
• Leveraging of the advanced release processes of K8up
• Better compatibility assurance between these two applications
• Complete testing behaviour
• Maybe more I cannot think of

[ccremer]

What is your idea of integration?
Do you speak about:

1. Make K8up a monorepo, have 2 "root" dirs, and keep K8up and wrestic seperate binaries (seperate go.mod)
2. Integrate the wrestic CLI options and logic into K8up binary itself, so multiple "modes" of K8up can run

In the second case, I can imagine creating a CLI out of K8up. The k8up operate (or whatever naming) command runs the K8up in Operator mode. When K8up schedules Jobs for restic, then it could set the command args like k8up check --other-flags but it's all in the same binary and the same image.

Going further with the CLI integration, we could make K8up also available for the user, e.g. to list available snapshots like k8up snapshot list or k8up restore --from-schedule test-schedule --revision latest (I'm just inventing stuff here). Since K8up in client mode would know the CRD specs etc. we won't need an API, but can interact directly with CRD objects and in client mode, K8up figures out how to restore which backup. Maybe that's an idea to keep in mind for K8up v2?

[tobru]

I haven't had a specific implementation in my mind when creating this topic, it's a tension I feel and this lead into starting this discussion.

While reading the proposal I first thought that the first one makes more sense. But having everything in the same codebase probably makes it much more integrated. It could end up as a single binary which acts differently depending on which command is called (I've seen this on many other projects already and quite like the single-binary approach). Another possibility would be to build several binaries out of the same codebase, for example the operator, "wrestic" and cli binary.

All in all I feel it would be a win-win situation to share the codebase to make use of all what's already available (CRD objects, release tooling, Git repo/issues, ...)

PS: Having a K8up cli is something we should absolutely consider, some more infos can be found internally in APPU-1902.

[Kidswiss]

The single binary for client and server seems very popular. Consul and Vault come to mind. I like the idea.

In case of Vault it's even three things:

• Server
• Agent
• CLI client

Something similar would be very cool for k8up.

[ccremer]

In comparison to Kubernetes, K8s uses (at least) an API repository, server and client repositories kept separate. However, the codebase of Kubernetes is also significantly larger than k8up.

I'm in favor of integrating restic here. It would also make e2e testing easier.
Actually, I'm on a private project in the exact same situation: Having Operator and CLI in the same binary and using subcommands as CLI args.
However, I would postpone this into K8up v2 and not into v1 anymore, this is too big for a minor change.

[tobru]

However, I would postpone this into K8up v2 and not into v1 anymore, this is too big for a minor change.

Absolutely, that's something for 2.x

[Kidswiss]

Opened #359 to move wrestic back into the main repo.

[ccremer]

Closing this discussion, we have integrated it already.