Crane kustomization support enhancement #57
Conversation
| - Should the `crane export`ed manifests be the base **OR** should we construct | ||
| a completely stripped base with the original and transform+apply manifests | ||
| defined as overlays **OR** (easiest) allow the transform+apply manifests to | ||
| be the base? |
There was a problem hiding this comment.
Originally, I thought that this was a question that needed to be answered as part of this enhancement. After spending some time thinking about it I no longer believe that to be the case.
We absolutely could provide this minimal level of Kustomize support, especially with GA considerations, and later expand that support in future releases.
| ["base"](https://kubectl.docs.kubernetes.io/references/kustomize/glossary/#base) | ||
| kustomization without modifying the original (aka "base") manifests. | ||
| It's important that Crane help users improve their situation when migrating | ||
| their applications. This enhancement proposes a new feature to the `apply` |
There was a problem hiding this comment.
Have we considered a new subcommand rather than an option?
I am wondering if this might be more ergonamic?
|
|
||
| ### Goals | ||
|
|
||
| - Allow user to further modify the results of `crane apply` with `kustomize` |
There was a problem hiding this comment.
I think we may want to reword the goal, or maybe I need to be convinced on this point.
My thought was that this was a feature for "Allow users to easily modernize they're exported and transformed manifests to a repeatable deployment tool".
WDYT? maybe this muddies the water more, but while you can modify results in both places this breaks the problem into two subsets. Changes that need to be made on export and changes that need to be made when repeatedly deploying into clusters?
There was a problem hiding this comment.
Yeah. Need to spend some more time refining the goal.
|
|
||
| ## Proposal | ||
|
|
||
| As the resources from `crane export` are iterated over: |
There was a problem hiding this comment.
could this be done on an output of an apply?
There was a problem hiding this comment.
@shawn-hurley I would think so. transform+apply produces a new yaml tree which is in the same format (with same filenames) as the export dir but with changes applied. Really, anything that takes an export dir as an input could be working on the results of an apply if the prior apply output dir is given as the export-dir param -- of course this includes transform+apply as well. You can absolutely transform and apply a set of resources that have previously been transformed and applied. Actually, I'd think for the kustomize use case the norm would be working on the output of apply rather than export, if I'm understanding the expected use cases correctly. Maybe we should use something like "input-dir" to make it clear that we're not necessarily talking about raw export results here.
No description provided.