Introduce "KnExport" type for defining an export format.

[rhuss]

Feature request

We have now kn service export which supports two modes for exporting revision: One which is directly usable with kubectl and uses a kind of "replay of services" to build up the service-configuration-revision graph and one which exports the service and revisions directly. However, the latter can not be applied directly to Kubernetes but only with a (still to build) kn service import as it needs to fix the ownerReferences (those can't be set from the outside).

The format suggested is:

apiVersion: client.knative.dev/v1alpha1
kind: Export
meta: 
   exportDate: ....
   name: ....
kind:
   service: 
         ... // a full Knative service spec
   revisions:   // list of Knative revisions, in creation order
   - ....

Ideally, it should be registered in a schema, using the same machinery as for CRDs in order to leverage cli-runtime output formats.

For the option --mode I suggest a renaming to better reflect the purpose:

• --mode replay --- Create a replay list of Knative Services
• --mode export --- To specify this new format. Not sure about the value we might use a name that better fits the purpose.

The main motivation to use a dedicated export type is to make it crystal clear that one can not import a bunch of Service and its Revisions with standard k8s tooling.

[rhuss]

bike shedding: I wonder whether this has to remain a client-side feature or would make also for a nice server-side feature by using this type as a real CRD ? In that case, a more "neutral" would make sense (like serving.knative.dev/Export)

[rhuss]

Well, maybe "export" is not the right wording here, as it focuses on the direction. Maybe "Transport" or "Transfer" is better suited ?

[itsmurugappan]

bike shedding: I wonder whether this has to remain a client-side feature or would make also for a nice server-side feature by using this type as a real CRD ? In that case, a more "neutral" would make sense (like serving.knative.dev/Export)

Server side feature means, controller would be reacting to the resource created right ? Then would'nt that work with kubectl apply itself ?

whether we have it at the client or server, crd needs to be packaged with serving install scripts.

[rhuss]

Yes, it would then work with kubectl as well, but then also "properly" as the server side controller is expected to set up the proper ownerrefs.

When we only use it only client side than no CRD is required. Its all about the client translating this yaml to the appropriate Knative Services and Revisions and apply them when using kn import. That way, if you use kubectl you will get an error because of an unkown type (so only kn can make sense out of the type).

[itsmurugappan]

for leveraging the cli-runtime output formats we need the crd right ?

[rhuss]

Yes, but that does not have to be registered at the server but only locally in the code via a schema . The idea to leverage the CRD machinery on the client side without actually deploying the CRD to the server.

[itsmurugappan]

/assign @itsmurugappan