Add --omit-component as inverse of --component

[rosskevin]

Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature

What happened:
Cannot --omit-component with any command, but you can include one with --component

What you expected to happen:
Should be able to omit if the goal is to support full stack deployments, and it is the companion/inverse of --component

How to reproduce it (as minimally and precisely as possible):

• ks show foo --component app.dbMigrate great! get just the migrate job manifest
• ks show foo --omit-component app.dbMigrate ouch! I need everything but the app.dbMigrate component

Anything else we need to know?:

• We have a spinnaker pipeline that must run database migrations as a job first, before deploying the rest of the stack
• After the job succeeds, the spinnaker pipeline continues to deploy the rest
• Because the dbMigrate component is setup virtually identical to the rest of our components such as api and sidekiq, these are all in a module named app. Therefore it isn't DRY to break it into another environment or different module, it reuses all the same params etc.
• Because we use some modules as tests for ingress etc, it's nice to have omit-module so that we don't have to delete or move these test modules out of the dir structure

Environment:
ksonnet version: 0.13.0
jsonnet version: v0.11.2
client-go version: kubernetes-1.10.4

I don't know go but it may help to know that this was important enough that I wrapped ks show with a nodejs script with the above functionality.
https://gist.github.com/rosskevin/12ed2dc43880e25b10763dc3f556a557

[rosskevin]

As I am getting down the path of doing blue/green deployments with spinnaker using the kubernetes manifest created by ksonnet and saved in github which triggers my pipeline, it is becoming more obvious that we need to pick and choose components for deployment at different stages. Therefore this kind of functionality is pretty critical.

For example, to accomplish blue/green deployment, I want to generate versioned deployments and matching version services, but I want the spinnaker pipeline to spin up the deployments and check the success first, then finally apply the versioned services change. If no good, apply the old versioned services manifest.

Anyway, I've got this covered in my wrapper right now but wanted to add a note that I'm finding this functionality useful/critical.

[rosskevin]

I've now added filtering by --module in addition to the --omit-component to get the staged publishing/validation we are seeking.

Example:

#!/usr/bin/env bash
set -e

MANIFESTS=${BASH_SOURCE%/*}/./environments/$1/manifests
rm -rf ${MANIFESTS} && mkdir ${MANIFESTS}

FILE=${MANIFESTS}/crt.yml
./show "$@" --module cert-manager > ${FILE}

FILE=${MANIFESTS}/app.yml
./show "$@" --module app --omit-component app.dbmigrate > ${FILE}

FILE=${MANIFESTS}dbmigrate.yml
./show "$@" --component app.dbmigrate > ${FILE}

FILE=${MANIFESTS}/inf.yml
./show "$@" --module traefik --module spinnaker > ${FILE}

[glerchundi]

Have the same idea and discovered that someone had it before me! How open you would be to add such flags?

/cc @shomron @bryanl

[glerchundi]

@rosskevin in the meantime i'm going to include conditionals:

params.jsonnet:

[...]
  "mycomponent": {
    migrate: false
  }
[...]

components/mycomponent.jsonnet:

[...]
if params.migrate then 
{
"kind": "Job"
}
else
{
"kind": "Deployment"
}
[...]