Giter Site home page Giter Site logo

patrickdappollonio / kubectl-slice Goto Github PK

View Code? Open in Web Editor NEW
279.0 5.0 21.0 228 KB

Split multiple Kubernetes files into smaller files with ease. Split multi-YAML files into individual files.

License: MIT License

Go 100.00%
kubectl-plugins kubectl-plugin kubectl yaml-parser yaml hacktoberfest

kubectl-slice's Introduction

kubectl-slice: split Kubernetes YAMLs into files

Downloads

kubectl-slice is a tool that allows you to split a single multi-YAML Kubernetes manifest (with --input-file or -f), or a folder containing multiple manifests files (with --input-folder or -d, optionally with --recursive), into multiple subfiles using a naming convention you choose. This is done by parsing the YAML code and allowing you to access any key from the YAML object using Go Templates.

By default, kubectl-slice will split your files into multiple subfiles following this naming convention that you can configure to your liking:

{{.kind | lower}}-{{.metadata.name}}.yaml

That is, the Kubernetes kind -- in this case, the value Namespace -- lowercased, followed by a dash, followed by the resource name -- in this case, the value production:

namespace-production.yaml

If your YAML includes multiple files, for example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-ingress
---
apiVersion: v1
kind: Namespace
metadata:
  name: production

Then the following files will be created:

$ kubectl-slice --input-file=input.yaml --output-dir=.
Wrote pod-nginx-ingress.yaml -- 58 bytes.
Wrote namespace-production.yaml -- 61 bytes.
2 files generated.

You can customize the file name to your liking, by using the --template flag.

Installation

kubectl-slice can be used as a standalone tool or through kubectl, as a plugin.

Using krew

kubectl-slice is available as a krew plugin.

To install, use the following command:

kubectl krew install slice

Download and install manually

Download the latest release for your platform from the Releases page, then extract and move the kubectl-slice binary to any place in your $PATH. If you have kubectl installed, you can use both kubectl-slice and kubectl slice (note in the later the absence of the -).

Usage

kubectl-slice allows you to split a YAML into multiple subfiles using a pattern.
For documentation, available functions, and more, visit: https://github.com/patrickdappollonio/kubectl-slice.

Usage:
  kubectl-slice [flags]

Examples:
  kubectl-slice -f foo.yaml -o ./ --include-kind Pod,Namespace
  kubectl-slice -f foo.yaml -o ./ --exclude-kind Pod
  kubectl-slice -f foo.yaml -o ./ --exclude-name *-svc
  kubectl-slice -f foo.yaml --exclude-name *-svc --stdout
  kubectl-slice -f foo.yaml --include Pod/* --stdout
  kubectl-slice -f foo.yaml --exclude deployment/kube* --stdout
  kubectl-slice -d ./ --recurse -o ./ --include-kind Pod,Namespace
  kubectl-slice -d ./ --recurse --stdout --include Pod/*
  kubectl-slice --config config.yaml

Flags:
      --allow-empty-kinds      if enabled, resources with empty kinds don't produce an error when filtering
      --allow-empty-names      if enabled, resources with empty names don't produce an error when filtering
  -c, --config string          path to the config file
      --dry-run                if true, no files are created, but the potentially generated files will be printed as the command output
      --exclude strings        resource name to exclude in the output (format <kind>/<name>, case insensitive, glob supported)
      --exclude-kind strings   resource kind to exclude in the output (singular, case insensitive, glob supported)
      --exclude-name strings   resource name to exclude in the output (singular, case insensitive, glob supported)
      --extensions strings     the extensions to look for in the input folder (default [.yaml,.yml])
  -h, --help                   help for kubectl-slice
      --include strings        resource name to include in the output (format <kind>/<name>, case insensitive, glob supported)
      --include-kind strings   resource kind to include in the output (singular, case insensitive, glob supported)
      --include-name strings   resource name to include in the output (singular, case insensitive, glob supported)
      --include-triple-dash    if enabled, the typical "---" YAML separator is included at the beginning of resources sliced
  -f, --input-file string      the input file used to read the initial macro YAML file; if empty or "-", stdin is used (exclusive with --input-folder)
  -d, --input-folder string    the input folder used to read the initial macro YAML files (exclusive with --input-file)
  -o, --output-dir string      the output directory used to output the splitted files
      --prune                  if enabled, the output directory will be pruned before writing the files
  -q, --quiet                  if true, no output is written to stdout/err
  -r, --recurse                if true, the input folder will be read recursively (has no effect unless used with --input-folder)
  -s, --skip-non-k8s           if enabled, any YAMLs that don't contain at least an "apiVersion", "kind" and "metadata.name" will be excluded from the split
      --sort-by-kind           if enabled, resources are sorted by Kind, a la Helm, before saving them to disk
      --stdout                 if enabled, no resource is written to disk and all resources are printed to stdout instead
  -t, --template string        go template used to generate the file name when creating the resource files in the output directory (default "{{.kind | lower}}-{{.metadata.name}}.yaml")
  -v, --version                version for kubectl-slice

Why kubectl-slice?

See why kubectl-slice? for more information.

Passing configuration options to kubectl-slice

Besides command-line flags, you can also use environment variables and a YAML configuration file to pass options to kubectl-slice. See the documentation for configuration options for details about both, including precedence.

Including and excluding manifests from the output

Including or excluding manifests from the output via metadata.name or kind is possible. Globs are supported in both cases. See the documentation for including and excluding items for more information.

Examples

See examples for more information.

Contributing & Roadmap

Pull requests are welcomed! So far, looking for help with the following items, which are also part of the roadmap:

kubectl-slice's People

Contributors

dependabot[bot] avatar douglasmakey avatar ianseyer avatar mathewpeterson avatar patrickdappollonio avatar renovate[bot] avatar ruzickap avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

kubectl-slice's Issues

Add support for processing Kubernetes list from "kubectl"

What did you do?

kubectl get -A all -o yaml > k8s.yml
go get github.com/patrickdappollonio/kubectl-slice
~/go/bin/kubectl-slice -f k8s.yml -o .

It installed v1.1.0.

What did you expect to see?

The list items be split to individual files.

What did you see instead?

One list-.yml file equal to the k8s.yml.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/codeql-analysis.yml
  • actions/checkout v3
  • github/codeql-action v2
  • github/codeql-action v2
  • github/codeql-action v2
.github/workflows/releasing.yaml
  • actions/checkout v3
  • actions/setup-go v3
  • golangci/golangci-lint-action v3
  • goreleaser/goreleaser-action v4
  • rajatjindal/krew-release-bot v0.0.43
.github/workflows/stale.yml
  • actions/stale v7
.github/workflows/testing.yml
  • actions/checkout v3
  • actions/setup-go v3
  • golangci/golangci-lint-action v3
gomod
go.mod
  • go 1.20
  • github.com/mb0/glob v0.0.0-20160210091149-1eb79d2de6c4@1eb79d2de6c4
  • github.com/spf13/cobra v1.6.1
  • github.com/stretchr/testify v1.8.1
  • golang.org/x/text v0.7.0
  • gopkg.in/yaml.v3 v3.0.1

  • Check this box to trigger a request for Renovate to run again on this repository

Output order of printed files should be preserved

What did you do?

Run the command from the README multiple times.

What did you expect to see?

$ kubectl-slice --input-file=example.yaml
Wrote pod-nginx-ingress.yaml -- 57 bytes.
Wrote namespace-production.yaml -- 60 bytes.
2 files generated.

... this being always the same output.

What did you see instead?

Depending on each call, the lines starting with Wrote will be mixed:

$ kubectl-slice --input-file=example.yaml
Wrote pod-nginx-ingress.yaml -- 57 bytes.
Wrote namespace-production.yaml -- 60 bytes.
2 files generated.
$ kubectl-slice --input-file=example.yaml
Wrote namespace-production.yaml -- 60 bytes.
Wrote pod-nginx-ingress.yaml -- 57 bytes.
2 files generated.

The order of the files should always be the same for the same input. I should sort these files before saving them.

The issue comes from using a map to store these. We could also use a Slice which will preserve the order.

Add support for "--filter"

Akin to --include-kind and --include-name and their --exclude-* counterparts (as well as #22), for more complex case scenarios it might be worth providing some sort of filtering where an expression is passed, and if the expression evaluates to true, then the fields are selected, otherwise they're excluded.

A good idea would be to look at implementing Google's Common Expression Language

Providing arguments to CLI on Windows PowerShell becomes difficult due to special characters

Hi, thanks for this tool!

This is not really and Issue anymore because I've managed to get it to work perfectly๐Ÿ‘, but maybe you can add this use-case to your examples folder?

  1. I downloaded metrics-server-0.6.1.yaml and first tried this command:
    kubectl-slice --template '{{.kind|lower}}/{{.metadata.name|dottodash}}.yaml' --input-file components.yaml --output-dir ./base
    Due to a colon in the name of a clusterrole-kind (system:aggregated-metrics-reader) I received an error.
  2. I tried adding a template function to replace ':' with '-' but got an error on:
    kubectl-slice --template '{{.kind|lower}}/{{.metadata.name|dottodash|replace ":" "-"}}.yaml' --input-file components.yaml --output-dir ./base
  3. So, the thing is: I'm on a windows machine and didn't get the replace function to work. So I've switched to a bash-shell. This works perfect, but maybe could be worth mentioning? Maybe also worth mentioning how to pipe multiple functions?

Cheers!

Add support for a configuration file

It would be useful for multiple case scenarios to support a configuration file instead of passing kubectl-slice settings via arguments. Arguments are not only cumbersome if they become long, but certain special characters that might be part of an argument might be handled differently per shell interpreter (see #53).

A proposal was made in #53 to include a "configuration file". To start, this file could be a YAML file with the name of .kubectl-slice.yaml in the current working directory (the dot being so it's treated as configuration). By default, the configuration file can be read from the current working directory, but optionally, it could be specified using --configuration /path/to/config.yaml which will allow not only to host the file in a place other than the current working directory but also rename the file to whatever the end user would prefer.

The configuration file could use viper (which plays well with spf13/cobra) to configure these settings from a file matching all the currently supported flags, and by using their exact same name as YAML arguments although in their long flag name form:

kubectl-slice/app.go

Lines 75 to 89 in ca0638a

rootCommand.Flags().StringVarP(&opts.InputFile, "input-file", "f", "", "the input file used to read the initial macro YAML file; if empty or \"-\", stdin is used")
rootCommand.Flags().StringVarP(&opts.OutputDirectory, "output-dir", "o", "", "the output directory used to output the splitted files")
rootCommand.Flags().StringVarP(&opts.GoTemplate, "template", "t", slice.DefaultTemplateName, "go template used to generate the file name when creating the resource files in the output directory")
rootCommand.Flags().BoolVar(&opts.DryRun, "dry-run", false, "if true, no files are created, but the potentially generated files will be printed as the command output")
rootCommand.Flags().BoolVar(&opts.DebugMode, "debug", false, "enable debug mode")
rootCommand.Flags().BoolVarP(&opts.Quiet, "quiet", "q", false, "if true, no output is written to stdout/err")
rootCommand.Flags().StringSliceVar(&opts.IncludedKinds, "include-kind", nil, "resource kind to include in the output (singular, case insensitive, glob supported)")
rootCommand.Flags().StringSliceVar(&opts.ExcludedKinds, "exclude-kind", nil, "resource kind to exclude in the output (singular, case insensitive, glob supported)")
rootCommand.Flags().StringSliceVar(&opts.IncludedNames, "include-name", nil, "resource name to include in the output (singular, case insensitive, glob supported)")
rootCommand.Flags().StringSliceVar(&opts.ExcludedNames, "exclude-name", nil, "resource name to exclude in the output (singular, case insensitive, glob supported)")
rootCommand.Flags().StringSliceVar(&opts.Included, "include", nil, "resource name to include in the output (format <kind>/<name>, case insensitive, glob supported)")
rootCommand.Flags().StringSliceVar(&opts.Excluded, "exclude", nil, "resource name to exclude in the output (format <kind>/<name>, case insensitive, glob supported)")
rootCommand.Flags().BoolVarP(&opts.StrictKubernetes, "skip-non-k8s", "s", false, "if enabled, any YAMLs that don't contain at least an \"apiVersion\", \"kind\" and \"metadata.name\" will be excluded from the split")
rootCommand.Flags().BoolVar(&opts.SortByKind, "sort-by-kind", false, "if enabled, resources are sorted by Kind, a la Helm, before saving them to disk")
rootCommand.Flags().BoolVar(&opts.OutputToStdout, "stdout", false, "if enabled, no resource is written to disk and all resources are printed to stdout instead")

(I've done a similar thing in http-server, here)

Opening this issue for two reasons: a) track the progress of this change; but b) ensure people can provide feedback. Namely, the format of the current file would look like this:

input_file: string
output_dir: string
template: string
dry_run: bool
debug: bool
quiet: bool
include_kind: []string
exclude_kind: []string
include_name: []string
exclude_name: []string
include: []string
exclude: []string
skip_non_k8s: bool
sort_by_kind: bool
stdout: bool

However an argument could be made that the format might differ from the flags into additional options (see #53 (comment) for an example).

Opening this for feedback. I'll wait a reasonable amount of time to implement this behaviour to make sure feedback is captured (or no feedback at all if it's been too long since opened with no comments).

Add support for "API group"

What did you do?

I have a bunch of manifests that need to be split by group and kind. I have two CRDs which both register an Application object (say, foo.example.com/v1/Application and bar.example.org/v1beta1/Application).

What did you expect to see?

Be able to extract only those Applications from foo.example.com and not those from bar.example.org.

What did you see instead?

All Applications are pulled, with no way to specify the group.

Alternatively, it might be worth also be able to target versions.

Add support for yaml-patch

It would be cool if the tool would support patching the YAML data using yaml-patch.

A good example would be adding an annotation to all resources, like github.com/patrickdappollonio/kubectl-slice: "true":

$ cat input.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-ingress
---
apiVersion: v1
kind: Namespace
metadata:
  name: production
$ cat patch.yaml
- op: add
  path: /metadata/annotations
  value: {}
- op: add
  path: /metadata/annotations/github.com~1patrickdappollonio~1kubectl-slice
  value: "true"

Then running kubectl-slice will render the files:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    github.com/patrickdappollonio/kubectl-slice: "true"
  name: nginx-ingress
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    github.com/patrickdappollonio/kubectl-slice: "true"
  name: production

Some unknowns though:

FIRST. If patching fails, do we error out? Do we warn and continue? A good example above is that our patch first needed to add the annotation otherwise it would've failed if we try to add the annotation directly, without creating the node first:

yamlpatch add operation does not apply: doc is missing path: /metadata/annotations/github.com~1patrickdappollonio~1kubectl-slice

SECOND. Do we apply filters before or after patching? For example, you could have a resource that doesn't have a kind: Foo but a patch that adds it. If you use --include-kind Foo then this resource would be added only after the patch is executed. So we need to decide if we patch-then-filter or filter-then-patch.

kubectl-slice does not slice file which uses Windows style line endings

What did you do?

  • Ran the command helm template . in PowerShell terminal in VS Code on Windows
  • Copied the output to Notepad++
  • Saved the text to complete.yaml
  • Ran the command kubectl-slice.exe -f complete.yaml -o .

What did you expect to see?

Multiple files generated

What did you see instead?

One file generated

When pasting the output into Notepad++ and saving to file the line endings got normalized to <CR><LF> causing kubectl-slice.exe to miss the lines with ---<CR><LF>

if line == "---\n" {

Suggestion: Use input file as a default argument

Thanks for the tool, today I faced the same issue that it tries to solve, and after a while of trying to get it done using yq I tried kubectl-slice and it worked exactly like I wanted from first try.

I have a suggestion that I thought it would make even more convenient: Allow inputFile as an argument in addition to the flag, and use . as a default output, the usage I imagine is something like this: kubectl-slice templates.yaml

Provide a Docker container with kubectl-slice inside

Some users have reached out asking for this app to be delivered via a container for multiple reasons:

  • Ability to plug it as part of a multi-stage build where they can extract the binary to another step
  • Ability to "run it without downloading it", just via docker.

The first option makes sense. It could even make sense to actually provide a Docker image with bash in it so people can run scripts and then rather than copying the binary in itself, they can simply run the action, grab the output, and pass it to another layer.

The 2nd option might be misleading: you're still downloading the app (alongside with an entire container for that matter). This could be helpful though in cases where a quick run "without installing" can be as simple as:

docker run -v $(pwd):/data ghcr.io/patrickdappollonio/kubectl-slice -f /data/example.yaml --stdout

Leaving this issue open to gather some feedback. If you're a user of the tool, and this might help you, I would love to know more, gauge sentiment and ship this!

Add support for silent operation

Hello,

I am using this module as a static library, for use within a Go application.

It would be great to be able to create a Split object that is silent (i.e. does not print anything to StdErr).

Add support for "--include" and "--exclude"

Now that --include-kind and --include-name and their --exclude-* counterparts are in, as well as supporting globs on either of them, I should add:

  • --include: to include any resource based on the format ${kind}/${name}
  • --exclude: to do the opposite

That way, you can do any of these queries:

kubectl-slice --include "deployment/*"
kubectl-slice --exclude "configmap/tekton-*"
kubectl-slice --include "deployments/*"

As a thing to note, it will always be ${kind}/${name}, and still TBD whether I parse ${kind} by itself, then ${name} or we treat the string as a whole. With the first case, this wouldn't be possible:

--include "deployment*" 

It will fail because there is no / separator. It will probably be better, because otherwise the example right above could capture, say, a CRD named DeploymentConfig (since the wildcard doesn't include an "end-of-word")

Add support for globs for Names and Kinds

Currently, --exclude-kind and --include-kind use an exact match (although case insensitive) of the Kubernetes kind field. It would be good if moving forward, and especially I add --exclude-name, for example, that the field should take globs.

There's a nifty library that can provide this kind of benefit: https://github.com/gobwas/glob, however it hasn't been updated in a while.

Add support to keep the triple dash at the beginning of splitted files

What did you do?

Simply run a split.
kubectl-slice -f file.yaml -o work

If I can.
Would it be possible for the output yamls, to leave the trailing --- for manifest separation.

---    # <--
apiVersion: apps/v1
kind: Deployment
metadata:

The goal here is to split in single manifest, to make it easier to costumize them, then remerge them after to one yaml file.

Multi-file yamls where the first file is commented results in an awkward parse

What did you do?

Tried to split this file:

# foo bar baz
# a b c
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-docker
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello-docker-app
  template:
    metadata:
      labels:
        app: hello-docker-app
    spec:
      containers:
        - name: hello-docker-container
          image: patrickdappollonio/hello-docker

What did you expect to see?

$ kubectl-split -f stack.yaml
Wrote deployment-hello-docker.yaml -- 332 bytes.
1 file generated.

One file generated since the other one seems to be just comments.

What did you see instead?

$ kubectl-split -f stack.yaml
Wrote -.yaml -- 22 bytes.
Wrote deployment-hello-docker.yaml -- 332 bytes.
2 files generated.

It's very common for Kubernetes YAMLs to have at least one comment out. The behaviour of the app here makes sense: if you open the -.yaml file you'll see the YAML was split and this file in particular contains:

# foo bar baz
# a b c

Technically it is the correct split: two files, one with the first YAML, and another with the second one, maintaining all comments from the original. The name is "botched" just because the template used by default would render no data for {{.kind | lower}}-{{.metadata.name}}.yaml keeping just the dash.

The questions here are:

  • Do we correct the parser to exclude splitting a file that's all comments (or potentially comments + random, non-Kubernetes YAML)?; or
  • do we keep the behaviour as-is, but add a validation or a warning that if the file name generated does not contain 1+ alphanumeric characters (as a sign of good faith since a file named -.yaml has probably no use) then warn, and potentially a mode that refuses to run if files have this warning?; or
  • do we strictly enforce that, since this is a Kubernetes-specific tool, all files must have at least apiVersion, kind and metadata.name?; or
  • do we keep the behaviour as-is since it's technically correct, but fix the default file name template {{.kind | lower}}-{{.metadata.name}}.yaml?; or
  • do we keep the behaviour as-is since it's technically correct, and not fix the default file name nor skip the entirely commented file?

Asking for public feedback, since I don't have a strong opinion on this.

Add support to specify a folder then recursively (or not) collect all YAML manifests

What did you do?

Every time I need to collect a bunch of YAML manifests just to render Ingresses I have to end up doing something like this:

find . \( -name "*.yml" -o -name "*.yaml" \) -exec sh -c 'for file; do echo "---"; cat "$file"; done' sh {} + > merged.yml && kubectl slice -f merged.yaml --stdout --include-kind Ingress

What did you expect to see?

  • A way to pass a -d for directory or a similarly named flag
  • A way to specify if I should find the top level yaml files vs recursively find them
  • A way to specify the file extension perhaps? (by default yml or yaml, since technically json would also work)

What did you see instead?

No way to specify the above

Windows - Can't pipe into slice

What did you do?

On Windows, when I run the following command:

helm template --debug . | kubectl slice -o generated

What did you expect to see?

I expect the flat rendered template to be piped into the slice command. I would see a directory labeled generated with the individual files

What did you see instead?

I get this error:

error: validation failed: unable to open file "/dev/stdin": open C:\dev\stdin: The system cannot find the path specified.
Error: exit status 1

Prevent requiring a "metadata.name" when using include/exclude kind flags

What did you do?

$ helm template my-release . -f values.yaml -f prod.yaml -n production | kubectl slice --exclude-kind Deployment,PodDisruptionBudget,Service -o output-prod

What did you expect to see?

All kinds except what was requested to be excluded. Including a List output as list-.yaml, which is normally output when no --include* or --exclude* flags are present.

Expected:

$ helm template my-release . -f values.yaml -f prod.yaml -n production | kubectl slice -o output-production-1
Wrote output-production-1/poddisruptionbudget-aaaa.yaml -- 241 bytes.
Wrote output-production-1/poddisruptionbudget-bbbb.yaml -- 245 bytes.
Wrote output-production-1/service-cccc.yaml -- 311 bytes.
Wrote output-production-1/service-dddd.yaml -- 278 bytes.
Wrote output-production-1/deployment-eeee.yaml -- 6040 bytes.
Wrote output-production-1/deployment-ffff.yaml -- 5603 bytes.
Wrote output-production-1/deployment-gggg.yaml -- 5587 bytes.
Wrote output-production-1/list-.yaml -- 3972 bytes.
8 files generated.

What did you see instead?

$ helm template my-release . -f values.yaml -f prod.yaml -n production | kubectl slice --exclude-kind Deployment,PodDisruptionBudget,Service -o output-production-2
error: unable to find Kubernetes "metadata.name" field in file number 8

^ File number 8 is the list.

If I'm just doing --exclude-kind, slice shouldn't care about metadata.name

Adding metadata.name does not make a difference.


I'm not personally looking to have lists split recursively like #28.

I really want slice to be more passive with lists. It expects to see metadata.name which runs fine when you don't use any --include* or exclude* flags.

Thanks!

Kustomize format (add shortcut/docs with apiVersion)

Hi,
Would you be open for being on-par with the Kustomize output format?

I.e. this:
kubernetes-sigs/kustomize#960

Essentially outputting into filenames containing all of:

  • apiVersion
  • kind
  • metadata.name

Possibly the same as this?
{{.apiVersion | lower}}_{{.kind | lower}}_{{.metadata.name | lower}}.yaml

For example:
v1_namespace_ns1.yaml
...from:

apiVersion: v1
kind: Namespace
metadata:
  name: ns1

Allow pruning contents of directory

What did you do?

I sliced the output of a kustomize build into separate files.
Later I sliced a newer version of the kustomize build, with fewer resources, but the files for the old resources missing from the new output were not pruned by kubectl-slice.

What did you expect to see?

I expected the slice to only retain files that came from the input file, and clean up (prune) files that don't belong there.
I hoped that it's just hidden behind a flag (eg. --prune), but no dice.
So best thing I could do is to wrap kubectl-slice with a custom shell script and do the pruning around kubectl-slice.
It would be great if the tool could itself prune and I wouldn't need to wrap it with a shell script.

What did you see instead?

No pruning. :(

Add support for printing to standard output

Another feature heard in social media is adding the ability to print the resources to standard output, rather than saving them to files.

While this idea is not in the core of kubectl-slice, it still maintains the idea that you can slice off certain YAML files. For example, one use case scenario could be printing only Deployments from an original YAML file, effectively slicing the rest. Something along these lines:

kubectl-slice -f input.yaml --include-kind Deployment --stdout

Assuming, of course, --stdout is the flag used to print to standard output.

This could allow neat things such as piping it to kubectl apply:

kubectl-slice -f input.yaml --include-kind Deployment --stdout | kubectl apply -f -

Or other actions that behave by piping the output to other programs.

The following questions remain:

One. How do we deal with the fact a filename template could've been passed? The following solutions come to my mind:

  • We fail running the program if someone provides a template and --stdout is set at the same time; or
  • We still print it, but, like Helm, we add an extra line at the beginning of the file with the name of the generated template name

Two. We would have to modify the binary behaviour from their original one where the logs for splitting files are printed to stdout and now print them to stderr, to make the binary pipe-friendly.

Opening the discussion to any potential user of this feature.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.