fluxctl install in the guides and new annotation docs

docs/faq.md

@@ -309,7 +309,7 @@ Yes. The easiest way to do that is to use the following annotation
 *in the manifest files*:
 
 ```yaml
-    flux.weave.works/ignore: true
+    fluxcd.io/ignore: true
 ```
 
 To stop ignoring these annotated resources, you simply remove the
@@ -329,7 +329,7 @@ If the annotation is just carried in the cluster, the easiest way
 to remove it is to run:
 
 ```sh
-kubectl annotate <resource> "flux.weave.works/ignore"-
+kubectl annotate <resource> "fluxcd.io/ignore"-
 ```
 
 Mixing both kinds of annotations (in-git and in-cluster), can make

docs/references/fluxctl.md

@@ -302,7 +302,7 @@ default:deployment/helloworld  helloworld  quay.io/weaveworks/helloworld:master-
 ```
 
 Automation can also be enabled by adding the annotation
-`flux.weave.works/automated: "true"` to the deployment.
+`fluxcd.io/automated: "true"` to the deployment.
 
 We can see that the `list-workloads` subcommand reports that the
 helloworld application is automated. Flux will now automatically
@@ -600,9 +600,10 @@ no existing author
 Automation and image tag filtering can also be managed using annotations
 (`fluxctl` is using the same mechanism).
 
-Automation can be enabled with `flux.weave.works/automated: "true"`. Image
+Automation can be enabled with `fluxcd.io/automated: "true"`. Image
 filtering annotations take the form
-`flux.weave.works/tag.container-name: filter-type:filter-value`. Values of
+`fluxcd.io/tag.<container-name>: <filter-type>:<filter-value>` or 
+`filter.fluxcd.io/<container-name>: <filter-type>:<filter-value>`. Values of
 `filter-type` can be [`glob`](#glob), [`semver`](#semver), and
 [`regexp`](#regexp). Filter values use the same syntax as when the filter is
 configured using `fluxctl`.
@@ -618,8 +619,8 @@ metadata:
   labels:
     app: podinfo
   annotations:
-    flux.weave.works/automated: "true"
-    flux.weave.works/tag.podinfod: semver:~1.3
+    fluxcd.io/automated: "true"
+    fluxcd.io/tag.podinfod: semver:~1.3
 spec:
   selector:
     matchLabels:
@@ -643,8 +644,8 @@ spec:
 Things to notice:
 
 1. The annotations are made in `metadata.annotations`, not in `spec.template.metadata`.
-2. The `flux.weave.works/tag.`... references the container name `podinfod`, this will change based on your container name. If you have multiple containers you would have multiple lines like that.
-3. The value for the `flux.weave.works/tag.`... annotation should includes the filter pattern type, in this case `semver`.
+2. The `fluxcd.io/tag.`... references the container name `podinfod`, this will change based on your container name. If you have multiple containers you would have multiple lines like that.
+3. The value for the `fluxcd.io/tag.`... annotation should includes the filter pattern type, in this case `semver`.
 
 Annotations can also be used to tell Flux to temporarily ignore certain manifests
-using `flux.weave.works/ignore: "true"`. Read more about this in the [FAQ](../faq.md).
+using `fluxcd.io/ignore: "true"`. Read more about this in the [FAQ](../faq.md).

docs/references/fluxyaml-config-files.md

@@ -101,7 +101,7 @@ commandUpdated:
       policy:
         command: >-
           cat flux-patch.yaml |
-          kubeyaml annotate --namespace $FLUX_WL_NS --kind $FLUX_WL_KIND --name $FLUX_WL_NAME "flux.weave.works/$FLUX_POLICY=$FLUX_POLICY_VALUE"
+          kubeyaml annotate --namespace $FLUX_WL_NS --kind $FLUX_WL_KIND --name $FLUX_WL_NAME "fluxcd.io/$FLUX_POLICY=$FLUX_POLICY_VALUE"
           > new-flux-patch.yaml &&
           mv new-flux-patch.yaml flux-patch.yaml
 ```
@@ -164,7 +164,7 @@ In addition, `updaters` are provided with some environment variables:
   * `FLUX_IMG`: Image name which the container needs to be updated to (e.g. `nginx`).
   * `FLUX_TAG`: Image tag which the container needs to be updated to (e.g. `1.15`).
 * `policy` updaters are provided with:
-  * `FLUX_POLICY`: the name of the policy to be added or updated in the workload. To make into an annotation name, prefix with `flux.weave.works/`
+  * `FLUX_POLICY`: the name of the policy to be added or updated in the workload. To make into an annotation name, prefix with `fluxcd.io/`
   * `FLUX_POLICY_VALUE`: value of the policy to be added or updated in the controller. If the `FLUX_POLICY_VALUE`
   environment variable is not set, it means the policy should be removed.
 

docs/references/helm-operator-integration.md

@@ -17,12 +17,16 @@ particular images to run, you will usually be able to update them with
 Flux, the same way you can with Deployments and so on.
 
 > **Note:** for automation to work, the repository _and_ tag should be
-> defined, as Flux determines image updates based on what it reads in
-> the `.spec.values` of the `HelmRelease`.
+> defined (either as a whole string, or under separate keys), as Flux
+> determines image updates based on what it reads in the `.spec.values`
+> of the `HelmRelease`.
+
+### Automated image detection
 
 Flux interprets certain commonly used structures in the `values`
-section of a `HelmRelease` as referring to images. The following
-are understood (showing just the `values` section):
+section of a `HelmRelease` as referring to images, at least an
+`image` key needs to be specified.  The following are understood
+(showing just the `values` section):
 
 ```yaml
 values:
@@ -78,21 +82,67 @@ values:
     port: 4040
 ```
 
+### Annotations
+
+If Flux does not automatically detect your image, it is possible to
+map the image paths by alias with YAML dot notation annotations. An
+alias overrules a detected image.
+
+The following annotations are available, you need to at least specify
+the `repository.fluxcd.io` annotation:
+
+| Annotation                    |                  |
+|-------------------------------|------------------|
+|`registry.fludcd.io/<alias>`   | `sub.reg`        |
+| `repository.fluxcd.io/<alias>`| `sub.repo`       |
+| `tag.fluxcd.io/<alias>`       | `sub.tag`        |
+| `filter.fluxcd.io/<alias>`    | `glob: master-*` |
+
+Two images specified in a `HelmRelease` as an example:
+
+```yaml
+metadata:
+  annotations:
+    # image and tag
+    repository.fluxcd.io/app: values.appImage
+    tag.fluxcd.io/app: values.appTag
+    filter.tag/app: 'glob: *'
+    # nested image with registry and tag
+    registry.fluxcd.io/submarine: values.sub.marinesystem.reg
+    repository.fluxcd.io/submarine: values.sub.marinesystem.img
+    tag.fluxcd.io/submarine: values.sub.marinesystem.tag
+
+spec:
+  values:
+    # image and tag
+    appImage: repo/image1
+    appTag: version
+    sub:
+      marinesystem:
+        # nested image with registry and tag
+        reg: domain.com
+        img: repo/image2
+        tag: version
+```
+
+#### Filter
+
 You can use the [same annotations](fluxctl.md) in
 the `HelmRelease` as you would for a Deployment or other workload,
 to control updates and automation. For the purpose of specifying
 filters, the container name is either `chart-image` (if at the top
-level), or the key under which the image is given (e.g., `"subsystem"`
-from the example above).
+level), the key under which the image is given (e.g., `"subsystem"`
+from the example above), or the alias you are using in your
+annotations.
 
 Top level image example:
 
 ```yaml
 kind: HelmRelease
 metadata:
   annotations:
-    flux.weave.works/automated: "true"
-    flux.weave.works/tag.chart-image: semver:~4.0
+    fluxcd.io/automated: "true"
+    fluxcd.io/tag.chart-image: semver:~4.0
 spec:
   values:
     image:
@@ -106,10 +156,10 @@ Sub-section images example:
 kind: HelmRelease
 metadata:
   annotations:
-    flux.weave.works/automated: "true"
-    flux.weave.works/tag.prometheus: semver:~2.3
-    flux.weave.works/tag.alertmanager: glob:v0.15.*
-    flux.weave.works/tag.nats: regex:^0.6.*
+    fluxcd.io/automated: "true"
+    fluxcd.io/tag.prometheus: semver:~2.3
+    fluxcd.io/tag.alertmanager: glob:v0.15.*
+    filter.fluxcd.io/nats: regex:^0.6.*
 spec:
   values:
     prometheus:

docs/tutorials/driving-flux.md

@@ -11,37 +11,12 @@ deployment](https://github.com/fluxcd/flux-get-started) and click on the
 
 ## Setup
 
-Get the source code of Flux:
+First, please [install `fluxctl`](../references/fluxctl.md).
 
-```sh
-git clone https://github.com/fluxcd/flux
-cd flux
-```
-
-In the next step, let's change the Git URL of Flux to point to our fork:
-
-```sh
-EDITOR deploy/flux-deployment.yaml
-```
-
-And update the following line
-
-```yaml
-    [email protected]:fluxcd/flux-get-started
-```
-
-to point to your fork, e.g. if your GitHub Login is `baloothebear`, the line
-above should be
-
-```yaml
-    [email protected]:baloothebear/flux-get-started
-```
-
-Save the file. For our simple case, that's all the configuration we need. Now
-it's time to deploy Flux. Simply run
+Then, run
 
 ```sh
-kubectl apply -f deploy
+fluxctl install [email protected]/<your-user>/flux-get-started [email protected] | kubectl apply -f -
 ```
 
 ### Alternative: Using Helm for the setup
@@ -106,9 +81,8 @@ namespace.
 The first step is done. Flux is now and up running (you can confirm by
 running `kubectl get pods --all-namespaces`).
 
-In the second step we will use fluxctl to talk to Flux in the cluster and
-interact with the deployments. First, please [install fluxctl](../references/fluxctl.md).
-(It enables you to drive all of Weave Flux, so have a look at the output of
+In the second step we will use `fluxctl` to talk to Flux in the cluster and
+interact with the deployments. (It enables you to drive all of Flux, so have a look at the output of
 `fluxctl -h` to get a better idea.)
 
 > **Note:** Another option (without installing `fluxctl` is to take a look
@@ -179,11 +153,11 @@ It should look a little something like this:
 @@ -8,8 +8,8 @@ metadata:
      app: podinfo
    annotations:
-     flux.weave.works/automated: "true"
--    flux.weave.works/tag.init: regexp:^3.*
--    flux.weave.works/tag.podinfod: semver:~1.3
-+    flux.weave.works/tag.init: glob:1.4.*
-+    flux.weave.works/tag.podinfod: glob:1.4.*
+     fluxcd.io/automated: "true"
+-    fluxcd.io/tag.init: regexp:^3.*
+-    fluxcd.io/tag.podinfod: semver:~1.3
++    fluxcd.io/tag.init: glob:1.4.*
++    fluxcd.io/tag.podinfod: glob:1.4.*
  spec:
    strategy:
      rollingUpdate:
@@ -223,10 +197,10 @@ The resulting diff should look like this
 @@ -10,6 +10,7 @@ metadata:
      app: podinfo
    annotations:
-     flux.weave.works/automated: "true"
-     flux.weave.works/tag.init: glob:1.4.*
-     flux.weave.works/tag.podinfod: glob:1.4.*
-+    flux.weave.works/locked: 'true'
+     fluxcd.io/automated: "true"
+     fluxcd.io/tag.init: glob:1.4.*
+     fluxcd.io/tag.podinfod: glob:1.4.*
++    fluxcd.io/locked: 'true'
  spec:
    strategy:
      rollingUpdate:
@@ -275,5 +249,5 @@ kubectl logs -n default deploy/flux -f
 ```
 
 If you should have any questions, find us on Slack in the [#flux
-channel](https://weave-community.slack.com/messages/flux/), get
-an invite to it [here](https://slack.weave.works/).
+channel](https://cncf.slack.com/messages/flux/), get
+an invite to it [here](https://slack.cncf.io).

docs/tutorials/get-started.md

@@ -16,7 +16,7 @@ will work as well though.
 
 ### A note on GKE with RBAC enabled
 
-If working on e.g. GKE with RBAC enabled, you will need to add a clusterrolebinding:
+If working on e.g. GKE with RBAC enabled, you will need to add a `ClusterRoleBinding`:
 
 ```sh
 kubectl create clusterrolebinding "cluster-admin-$(whoami)" --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
@@ -32,37 +32,21 @@ extra privileges:
 
 ## Set up Flux
 
-Get Flux:
+In our example we are going to use
+[flux-get-started](https://github.com/fluxcd/flux-get-started). If you
+want to use that too, be sure to create a fork of it on GitHub.
 
-```sh
-git clone https://github.com/fluxcd/flux
-cd flux
-```
+First, please [install `fluxctl`](../references/fluxctl.md).
 
-Now you can go ahead and edit Flux's deployment manifest. At the very
-least you will have to change the `--git-url` parameter to point to
-the config repository for the workloads you want Flux to deploy for
-you. You are going to need access to this repository.
+Then, install flux in your Cluster:
 
 ```sh
-$EDITOR deploy/flux-deployment.yaml
+fluxctl install [email protected]/<your-user>/flux-get-started --git-path=namespaces,workloads [email protected] | kubectl apply -f -
 ```
 
-In our example we are going to use [`fluxcd/flux-get-started`](https://github.com/fluxcd/flux-get-started).
-If you want to use that too, be sure to create a fork of it on GitHub
-and add the git URL to the config file above. After that, set the
-`--git-path` flag to `--git-path=namespaces,workloads`, this is meant
-to exclude Helm manifests. Again, if you want to get started with Helm,
-please refer to the ["Get started with Flux using Helm"](get-started-helm.md)
-tutorial.
-
-## Deploying Flux to the cluster
-
-In the next step, deploy Flux to the cluster:
-
-```sh
-kubectl apply -f deploy
-```
+`--git-path=namespaces,workloads`, is meant to exclude Helm
+manifests. Again, if you want to get started with Helm, please refer to the
+[Helm section](get-started-helm.md).
 
 Allow some time for all containers to get up and running. If you're
 impatient, run the following command and see the pod creation
@@ -75,7 +59,7 @@ watch kubectl get pods --all-namespaces
 ## Giving write access
 
 At startup Flux generates a SSH key and logs the public key. Find
-the SSH public key by installing [fluxctl](../references/fluxctl.md) and
+the SSH public key by installing [`fluxctl`](../references/fluxctl.md) and
 running:
 
 ```sh