Add whitelist to examples

[Aergonus]

As per #78, this will help people who want to come in and deploy quickly. I think when I made the PR to add whitelists we discussed the default whitelist behavior and decided to err on the safe side and whitelist only the default namespace rather than not have a whitelist.

[asobti]

Taking a step back, what's the purpose of the whitelist in the first place? By adding the kube-monkey labels to their app, they are effectively whitelisting that app. Why the need to further add that namespace to this whitelist?

[asobti]

One of the advantages of enabling apps for kube-monkey by adding labels to them was to allow apps to be enrolled/un-enrolled without having to reconfigure and restart kube-monkey, since kube-monkey forgets its current schedule everytime it gets restarted.

[Aergonus]

People wanted a opt in whitelist for namespaces as well. I think it makes sense since people I've met have had strong opinions of having one k8s cluster with namespaces for dev, prod, etc. The whitelist is a step towards opt in with defaults for namespaces. Right now for the people that had many namespaces and didn't want to blacklist a possibly changing list, the whitelist allows for simplified use.

…

On Mon, Jul 9, 2018, 6:42 PM Ayush Sobti ***@***.***> wrote: One of the advantages of enabling apps for kube-monkey by adding labels to them was to allow apps to be enrolled/un-enrolled without having to reconfigure and restart kube-monkey, since kube-monkey forgets its current schedule everytime it gets restarted. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#82 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACV_i2yp4wwzUpJcmbNpQuDhQArI2Fjcks5uE9xkgaJpZM4VIcik> .

[asobti]

People wanted a opt in whitelist

I always understood that as a request for the ability to automatically have all apps within the whitelisted namespaces be potential victims for kube-monkey, without the need to add the kube-monkey labels to each app.

In your scenario, where they have the same app running in multiple namespaces (dev, staging, live etc.), why not just add the kube-monkey labels only in the namespaces you want kube-monkey to run in?

for eg:

app: web-frontend
namespace: dev
labels:
  kube-monkey/enabled: enabled
  ...

app: frontend
namespace: prod
labels:
  kube-monkey/enabled: disabled

[Aergonus]

True, with opt-in it's kind of redundant. Making the whitelist default all namespaces and tracking the whitelist opt-out in #5 makes sense to me. The option can stay as a no-op feature or if someone needs to convince their management that it definitely won't affect other namespaces.

[asobti]

Thanks. Could you also remove line 14

https://github.com/asobti/kube-monkey/blob/master/examples/configmap.yaml#L14

[Aergonus]

Good catch, do you prefer to remove it from the README as well until it works as opt in? That's the last public trace of it.