"kubectl create" includes the ability to create specific resource types using a simple interface with command line arguments that populate the spec of the created resources, in some cases with data conversion. This simplifies the user experience.
kubectl create can not be extended to understand new types and the crossplane-cli does not offer this experience.
How can Crossplane improve this?
"kubectl crossplane" should include a "create" command that can perform a similar role for Crossplane's claim and class types. For the core types the CLI can include help describing the parameters available, and any data format or content conversions that the CLI performs.
If this is implemented dynamically (generically), for "crossplane create" types, structured spec data may be harder to support. We would not have helper conversion functions available for these parameters.
Dynamic documentation may be adapted from kubectl explain facilities which is drawn from the CRD itself. An approach to list all CRDs owned by Stacks would be needed.
One benefit of a dynamic approach is that this command could easily provide a create command for all managed resource, claim, and class types for all installed stacks.
One (static) approach would be to create scripts such as "kubectl-crossplane-create-mysqlinstance" for each type.
This approach would keep the code easy to review, allow for different implementations (languages) per resource, and would suggest that stack authors may provide similar plugins for their stack resource types.
What is the problem you are facing?
"kubectl create" includes the ability to create specific resource types using a simple interface with command line arguments that populate the spec of the created resources, in some cases with data conversion. This simplifies the user experience.
kubectl createcan not be extended to understand new types and the crossplane-cli does not offer this experience.How can Crossplane improve this?
"kubectl crossplane" should include a "create" command that can perform a similar role for Crossplane's claim and class types. For the core types the CLI can include help describing the parameters available, and any data format or content conversions that the CLI performs.
If this is implemented dynamically (generically), for "crossplane create" types, structured spec data may be harder to support. We would not have helper conversion functions available for these parameters.
Dynamic documentation may be adapted from
kubectl explainfacilities which is drawn from the CRD itself. An approach to list all CRDs owned by Stacks would be needed.One benefit of a dynamic approach is that this command could easily provide a create command for all managed resource, claim, and class types for all installed stacks.
One (static) approach would be to create scripts such as "kubectl-crossplane-create-mysqlinstance" for each type.
This approach would keep the code easy to review, allow for different implementations (languages) per resource, and would suggest that stack authors may provide similar plugins for their stack resource types.