Add "kn service export"

[rhuss]

In what area(s)?

Describe the feature:

A kn service export should export a specific Knative service in yaml/json so that it can be easily recreated. It's different to kn service describe -o yaml as it strips all runtime specific elements like the status and metadata like the namespace. The idea is that the exported description can be easily committed to a CM system and re-created with kn service import (or kubectl apply -f if direct Kubernetes access is possible).

An extension could be to allow also an export of all attached revisions (like with --history), but that would imly also to export owner references and not sure whether revisions can be created manually.

[duglin]

I like this idea - it will also help with people who want to learn about Kn by easily seeing how someone else created their KnService.

[itsmurugappan]

@rhuss Can I work on this ? Recently did something similar for my cluster.
https://github.com/itsmurugappan/k8s-resource-backup
My intention was to back up the knative resources and restore if there was an issue. While restoring, if the service had multiple revisions with traffic splitting it was tricky, I had to apply the service for each revision and then apply the traffic changes.

For example if service had 2 revisions v1 and v2
When backing up, I saved the ksvc and all revisions, while restoring, first I created ksvc with the spec of revision v1 , then i updated the ksvc with spec of revision v2, then finally updated the traffic.
Please let me know if there is a simpler way to do it.

[rhuss]

Can I work on this ?

@itsmurugappan Yes sure! Let's get it started ;-)

I think first we should do a plain export for a naked service without revision history. This, of course, works only when there is no traffic split, so probably only for simple cases (too simplistic ?).

The other case, to export / import also the revisions (ideally only those referenced in a traffic section of a service, but maybe with an option also the full history, or say, the last n revision) it gets tricky.

I'm not sure if one can create Revisions directly or whether an admission controller forbids this. If this is possible we could create older revisions directly and then connect it to the parent service by setting the ownerReference manually (option A)

The solution that you suggest should also work but it involves quite some spin up/down of Pods which could have strange side effects (but at least will take some time). But its definitely an option (option B)

So, I would first check whether option A) would be possible. But also if it is "allowed" (so would ask this on #serving-api slack)
Also, we should checkout the old PR for a kn migrate (#406)as it solves a similar problem (but is not yet merged for some reasons).

[itsmurugappan]

Thanks @rhuss I will get started with the plain export first.

[rhuss]

@itsmurugappan thanks a lot for your work ! I think as a next step we can now think to maybe export the revisions directly, a first check show that you can import them. So we could already export them with the proper ownerReferences, this would avoid the issue with building up the revisions implicitly as it's now.

we need to rearrange the printers a bit, but that should be feasible.

[itsmurugappan]

@rhuss I will give it a try with revisions. First i will fix all the review comments you had mentioned in the PR.