Questions about validation and bounded setters/substituation

[mle...@gmail.com]

Hello,

I trying to wrap my head around what kpt is good at and what I should use it for.

* Could kpt functions be used to validate crds are using non deprecated apis?

* Does it make sense that a setter or substitution could be bounded?

  * so you could set the image to only be docker.io/prod or gitlab/prod

  * or substutition of a version could be only valid versions or supported versions or something like that?

I hope that makes sense

Regards,

[mle...@gmail.com]

More questions:

* is the only way to undeploy an set of resources is to delete the yaml file?

Does it make sense to have a kpt delete my-cool-pkg? maybe with options on what you want to delete + confirm?

[Phani Teja Marupaka]

 trying to wrap my head around what kpt is good at and what I should use it for.

* Could kpt functions be used to validate crds are using non deprecated apis?

Kpt functions can validate local resource configuration, including CRDs.  Can you quote an example for "using non deprecated apis"?

 

* Does it make sense that a setter or substitution could be bounded?

  * so you could set the image to only be docker.io/prod or gitlab/prod

  * or substutition of a version could be only valid versions or supported versions or something like that?

This is a use case we are definitely considering.  Setters and substitutions are defined as OpenAPI extensions, so the possibility of using OpenAPI to restrict values is absolutely something that makes sense.  (e.g. a regex, number range, enumerations, etc).  Support for this has not yet been implemented.  Please file an issue. 

 

* is the only way to undeploy an set of resources is to delete the yaml file?

If you have deployed your package using kpt live apply, you may use kpt live destroy to undeploy/delete resources of your entire package from the cluster, without needing to delete the yaml files. However, if you want to delete/undeploy specific resources in a package deployed with kpt live apply, you must delete the resource file and then trigger kpt live apply. We've also considered supporting an annotation to declaratively delete resources in file without needing to delete the file itself. You may file an issue for that.

If you are a kubectl fan and haven't tried kpt live yet, you may use kubectl to delete resources as well, perhaps `kubectl delete -R -f dir/` would work for you?  If the resources are in a namespace, deleting the namespace may be an option as well. 

Regards

Phani.

--
You received this message because you are subscribed to the Google Groups "kpt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kpt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kpt-users/481eb80d-f6ca-4d54-aa4c-75e7efb7f158%40googlegroups.com.

[mle...@gmail.com]

Kpt functions can validate local resource configuration, including CRDs.  Can you quote an example for "using non deprecated apis"?

Say you had a ingress and the version moved to v1 in some new version of k8s:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
...

kpt fn run proj  --image lint-crd

Does that make sense as a use case?

Also what would be best practice for persistent volume claims? I would like to not destroy the persistent state of a package.

To unsubscribe from this group and stop receiving emails from it, send an email to kpt-...@googlegroups.com.

[mle...@gmail.com]

another question: does kpt allow for the creation of namespaces? destroy looks to remove it but apply errors when trying to create a namespace. What is the best practice for namespaces

[Phillip Wittrock]

Regarding deprecated APIs, yes you can write a function to validate that no deprecated APIs are being used directly by the configuration.  You would probably want to bake into the function which APIs are deprecated for each version of Kubernetes, and write the function to take a Kubernetes version as input.

Then you could run `kpt fn run DIR/ --image deprecated-apis:v1 -- version=1.18`

Alternatively, you could make the container version coupled to the Kubernetes apiVersion: `kpt fn run DIR/ --image deprecated-apis:1.18`

 While the function could get the APIs from the cluster directly, this pattern is generally discouraged as it isn't hermetic.

To unsubscribe from this group and stop receiving emails from it, send an email to kpt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kpt-users/a7604b48-82c2-4192-b954-2959bf364e9e%40googlegroups.com.

[Phani Teja Marupaka]

• Also what would be best practice for persistent volume claims? I would like to not destroy the persistent state of a package.

That will be implemented as part of life cycle directives(ex: Do not delete) in coming releases. Stay tuned. For now, you can leverage kpt live preview in order to make sure that the configuration changes don't perform unwanted actions when applied through kpt live apply.

• does kpt allow for the creation of namespaces? destroy looks to remove it but apply errors when trying to create a namespace. What is the best practice for namespaces

kpt live apply allows creation of namespaces. However, you can deploy resources in directory/package to a single namespace only currently. We will be expanding the capability to support multiple namespaces per grouping/directory in coming releases. The best practice for now is to maintain different grouping/directory for resources belonging to different namespaces.

To view this discussion on the web visit https://groups.google.com/d/msgid/kpt-users/CAPzFYDvqwDYJjxPRnNdJmYzQvXQhOEz3jE-pk48y8EegQPabTA%40mail.gmail.com.