Updated readme.md and user facing files

README.md

@@ -10,13 +10,13 @@ Kubernetes supports declarative management of objects using configurations writt
 
 Kyverno allows cluster adminstrators to manage environment specific configurations independently of workload configurations and enforce configuration best practices for their clusters.
 
-Kyverno policies are Kubernetes resources that can be written in YAML or JSON. Kyverno policies can validate, mutate, and generate any Kubernetes resources. 
+Kyverno policies are Kubernetes resources that can be written in YAML or JSON. Kyverno policies can validate, mutate, and generate any Kubernetes resources.
 
 Kyverno runs as a [dynamic admission controller](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) in a Kubernetes cluster. Kyverno receives validating and mutating admission webhook HTTP callbacks from the kube-apiserver and applies matching policies to return results that enforce admission policies or reject requests.
 
 Kyverno policies can match resources using the resource kind, name, and label selectors. Wildcards are supported in names.
 
-Mutating policies can be written as overlays (similar to [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays)) or as a [JSON Patch](http://jsonpatch.com/). Validating policies also use an overlay style syntax, with support for pattern matching and conditional (if-then-else) processing. 
+Mutating policies can be written as overlays (similar to [Kustomize](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays)) or as a [JSON Patch](http://jsonpatch.com/). Validating policies also use an overlay style syntax, with support for pattern matching and conditional (if-then-else) processing.
 
 Policy enforcement is captured using Kubernetes events. Kyverno also reports policy violations for existing resources.
 
@@ -46,8 +46,8 @@ spec:
           - name: "*"
             resources:
               limits:
-                # '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters. 
+                # '?' requires 1 alphanumeric character and '*' means that there can be 0 or more characters.
-                # Using them togther e.g. '?*' requires at least one character. 
+                # Using them together e.g. '?*' requires at least one character. 
                 memory: "?*"
                 cpu: "?*"
               requests:
@@ -100,7 +100,7 @@ spec:
       selector:
         matchExpressions:
         - {key: kafka, operator: Exists}
-    generate: 
+    generate:
       kind: ConfigMap
       name: zk-kafka-address
       data:
@@ -126,11 +126,11 @@ Additional examples are available in [examples](/examples).
 
 ### Open Policy Agent
 
-[Open Policy Agent (OPA)](https://www.openpolicyagent.org/) is a general-purpose policy engine that can be used as a Kubernetes admission controller. It supports a large set of use cases. Policies are written using [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies#what-is-rego) a custom query language. 
+[Open Policy Agent (OPA)](https://www.openpolicyagent.org/) is a general-purpose policy engine that can be used as a Kubernetes admission controller. It supports a large set of use cases. Policies are written using [Rego](https://www.openpolicyagent.org/docs/latest/how-do-i-write-policies#what-is-rego) a custom query language.
 
 ### Polaris
 
-[Polaris](https://github.com/reactiveops/polaris) validates configurations for best practices. It includes several checks across health, networking, security, etc. Checks can be assigned a severity. A dashboard reports the overall score. 
+[Polaris](https://github.com/reactiveops/polaris) validates configurations for best practices. It includes several checks across health, networking, security, etc. Checks can be assigned a severity. A dashboard reports the overall score.
 
 ### External configuration management tools
 
@@ -166,7 +166,6 @@ Here are some the major features we plan on completing before a 1.0 release:
 
 Welcome to our community and thanks for contributing!
 
-  * Please review and agree to abide with the [Code of Conduct](/CODE_OF_CONDUCT.md) before contributing. 
+  * Please review and agree to abide with the [Code of Conduct](/CODE_OF_CONDUCT.md) before contributing.
   * See the [Wiki](https://github.com/nirmata/kyverno/wiki) for developer documentation.
   * Browse through the [open issues](https://github.com/nirmata/kyverno/issues)
-

documentation/writing-policies-mutate.md

@@ -1,6 +1,6 @@
 <small>*[documentation](/README.md#documentation) / [Writing Policies](/documentation/writing-policies.md) / Mutate*</small>
 
-# Mutate Configurations 
+# Mutate Configurations
 
 The ```mutate``` rule contains actions that will be applied to matching resource before their creation. A mutate rule can be written as a JSON Patch or as an overlay. By using a ```patch``` in the (JSONPatch - RFC 6902)[http://jsonpatch.com/] format, you can make precise changes to the resource being created. Using an ```overlay``` is convenient for describing the desired state of the resource.
 
@@ -47,7 +47,8 @@ spec :
   rules:
     - name: "Remove unwanted label"
       resource:
-        kind: Secret
+        kinds:
+          - Secret
       mutate:
         patches:
         - path: "/metadata/labels/purpose"
@@ -71,7 +72,8 @@ spec :
   rules:
     - name: "Set hard memory limit to 2Gi"
       resource:
-        kind: Pod
+        kinds:
+          - Pod
         selector:
           matchLabels:
             memory: high
@@ -80,7 +82,7 @@ spec :
           spec:
             containers:
             # the wildcard * will match all containers in the list
-            - name: *
+            - (name): "*"
               resources:
                 requests:
                   memory: "10Gi"
@@ -91,40 +93,44 @@ spec :
 
 ### Working with lists
 
-Applying overlays to a list type without is fairly straightforward: new items will be added to the list, unless they already ecist. For example, the next overlay will add IP "192.168.10.172" to all addresses in all Endpoints:
+Applying overlays to a list type without is fairly straightforward: new items will be added to the list, unless they already exist. For example, the next overlay will add IP "192.168.10.172" to all addresses in all Endpoints:
 
 ````yaml
-apiVersion: policy.nirmata.io/v1alpha1
+apiVersion: kyverno.io/v1alpha1
 kind: Policy
 metadata:
   name: policy-endpoints
 spec:
   rules:
-  - resource:
+  - name: "Add IP to subsets"
-      kind : Endpoints
+    resource:
+      kinds :
+        - Endpoints
     mutate:
       overlay:
         subsets:
         - addresses:
-          - ip: 192.168.10.172
+          - ip: 192.168.42.172
 ````
 
 
 ### Conditional logic using anchors
 
-An **anchor** field, marked by parentheses, allows conditional processing of configurations. Processing stops when the anchor value does not match. Once processing stops, any child elements or any remaining siblings in a list, will not be processed. 
+An **anchor** field, marked by parentheses, allows conditional processing of configurations. Processing stops when the anchor value does not match. Once processing stops, any child elements or any remaining siblings in a list, will not be processed.
 
  For example, this overlay will add or replace the value 6443 for the port field, for all ports with a name value that starts with "secure":
 
 ````yaml
-apiVersion : policy.nirmata.io/v1alpha1
+apiVersion: kyverno.io/v1alpha1
 kind : Policy
 metadata :
   name : policy-set-port
 spec :
   rules:
-  - resource:
+  - name: "Set port"
-      kind : Endpoints
+    resource:
+      kinds :
+        - Endpoints
     mutate:
       overlay:
         subsets:
@@ -145,18 +151,20 @@ A variation of an anchor, is to add a field value if it is not already defined.
  For example, this overlay will set the port to 6443, if a port is not already defined:
 
 ````yaml
-apiVersion : policy.nirmata.io/v1alpha1
+apiVersion: kyverno.io/v1alpha1
 kind : Policy
 metadata :
   name : policy-set-port
 spec :
   rules:
-  - resource:
+  - name: "Set port"
-      kind : Endpoints
+    resource:
+      kinds :
+        - Endpoints
     mutate:
       overlay:
         subsets:
-        - ports:
+        - (ports):
             +(port): 6443
 ````
 

test/README.md

@@ -46,7 +46,7 @@ metadata :
   name : policy-endpoints
 spec :
   rules:
-    - name:
+    - name: ""
       resource:
         kinds:
           - Endpoints