From 5e549fa882f29c368b17ee820e07f72947f8c166 Mon Sep 17 00:00:00 2001
From: Hidde Beydals <hello@hidde.co>
Date: Tue, 30 Jul 2019 18:14:54 +0200
Subject: [PATCH 1/3] Restructure and split Flux and Helm op docs
---
CONTRIBUTING.md | 8 +-
README.md | 22 +-
chart/flux/README.md | 10 +-
.../deployment-pipeline.png | Bin
docs/{images => _files}/flux-cd-diagram.png | Bin
docs/{images => _files}/weave-flux.png | Bin
docs/contributing/building.md | 33 ++
docs/contributing/get-started-developing.md | 287 ++++++++++++++++++
docs/contributing/index.rst | 11 +
docs/development/building.md | 28 --
docs/development/get-started-developing.md | 211 -------------
docs/development/index.rst | 15 -
docs/faq.md | 77 ++---
docs/features/index.rst | 16 -
docs/{install => get-started}/index.rst | 27 +-
docs/guides/index.rst | 12 +
docs/guides/provide-own-ssh-key.md | 36 +++
docs/{using => guides}/upgrading-to-1.0.md | 16 +-
docs/guides/use-private-git-host.md | 87 ++++++
docs/helm-operator/faq.md | 42 +++
docs/helm-operator/guides/index.rst | 10 +
.../guides/upgrading-to-beta.md} | 6 +-
docs/helm-operator/index.rst | 15 +
.../helmrelease-custom-resource.md} | 201 ++----------
docs/helm-operator/references/index.rst | 11 +
docs/helm-operator/references/operator.md | 40 +++
docs/helm-operator/troubleshooting.md | 27 ++
.../tutorials/get-started.md} | 66 +---
docs/helm-operator/tutorials/index.rst | 10 +
docs/helm/index.rst | 14 -
docs/index.rst | 35 ++-
docs/install/index.md | 17 --
docs/install/standalone-setup.md | 187 ------------
.../blueprint.md} | 17 +-
docs/{features => references}/daemon.md | 60 ++--
docs/{using => references}/fluxctl.md | 14 +-
.../fluxyaml-config-files.md | 6 +-
.../garbagecollection.md | 14 +-
docs/{using => references}/git-gpg.md | 0
docs/references/helm-operator-integration.md | 123 ++++++++
docs/references/index.rst | 17 ++
docs/{using => references}/monitoring.md | 0
docs/troubleshooting.md | 46 +--
.../driving-flux.md} | 12 +-
.../get-started-helm.md} | 28 +-
docs/{install => tutorials}/get-started.md | 85 +++---
docs/tutorials/index.rst | 12 +
docs/using/index.rst | 16 -
internal_docs/releasing.md | 2 +-
49 files changed, 1031 insertions(+), 998 deletions(-)
rename docs/{images => _files}/deployment-pipeline.png (100%)
rename docs/{images => _files}/flux-cd-diagram.png (100%)
rename docs/{images => _files}/weave-flux.png (100%)
create mode 100644 docs/contributing/building.md
create mode 100644 docs/contributing/get-started-developing.md
create mode 100644 docs/contributing/index.rst
delete mode 100644 docs/development/building.md
delete mode 100644 docs/development/get-started-developing.md
delete mode 100644 docs/development/index.rst
delete mode 100644 docs/features/index.rst
rename docs/{install => get-started}/index.rst (52%)
create mode 100644 docs/guides/index.rst
create mode 100644 docs/guides/provide-own-ssh-key.md
rename docs/{using => guides}/upgrading-to-1.0.md (89%)
create mode 100644 docs/guides/use-private-git-host.md
create mode 100644 docs/helm-operator/faq.md
create mode 100644 docs/helm-operator/guides/index.rst
rename docs/{helm/helm-upgrading-to-beta.md => helm-operator/guides/upgrading-to-beta.md} (96%)
create mode 100644 docs/helm-operator/index.rst
rename docs/{helm/helm-integration.md => helm-operator/references/helmrelease-custom-resource.md} (72%)
create mode 100644 docs/helm-operator/references/index.rst
create mode 100644 docs/helm-operator/references/operator.md
create mode 100644 docs/helm-operator/troubleshooting.md
rename docs/{helm/helm-operator.md => helm-operator/tutorials/get-started.md} (55%)
create mode 100644 docs/helm-operator/tutorials/index.rst
delete mode 100644 docs/helm/index.rst
delete mode 100644 docs/install/index.md
delete mode 100644 docs/install/standalone-setup.md
rename docs/{how-it-works.md => references/blueprint.md} (87%)
rename docs/{features => references}/daemon.md (83%)
rename docs/{using => references}/fluxctl.md (99%)
rename docs/{features => references}/fluxyaml-config-files.md (97%)
rename docs/{features => references}/garbagecollection.md (84%)
rename docs/{using => references}/git-gpg.md (100%)
create mode 100644 docs/references/helm-operator-integration.md
create mode 100644 docs/references/index.rst
rename docs/{using => references}/monitoring.md (100%)
rename docs/{using/annotations-tutorial.md => tutorials/driving-flux.md} (95%)
rename docs/{install/helm-get-started.md => tutorials/get-started-helm.md} (87%)
rename docs/{install => tutorials}/get-started.md (62%)
create mode 100644 docs/tutorials/index.rst
delete mode 100644 docs/using/index.rst
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 9f388c35c..a8c8bbb8f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -18,8 +18,8 @@ the `blocked-needs-validation` label is removed, and the issue can be worked
on.
To set up Flux to test things, there's documentation about setting up a
-[standalone install](docs/install/get-started.md) and a [Helm
-install](docs/install/helm-get-started.md), which might be helpful.
+[standalone install](docs/tutorials/get-started.md) and a [Helm
+install](docs/tutorials/get-started-helm.md), which might be helpful.
Please talk to us on Slack, if you should get stuck anywhere. We appreciate
any help and look forward to talking to you soon!
@@ -73,10 +73,10 @@ This is a rough outline of how to prepare a contribution:
### How to build and run the project
-Refer to the [building doc](docs/development/building.md) to find out how to build from
+Refer to the [building doc](docs/contributing/building.md) to find out how to build from
source.
-Refer to the [Get Started Developing](docs/development/get-started-developing.md) guide for a walkthrough on developing Flux locally.
+Refer to the [Get Started Developing](docs/contributing/get-started-developing.md) guide for a walkthrough on developing Flux locally.
### How to run the test suite
diff --git a/README.md b/README.md
index 474624e4e..6ba306cfe 100644
--- a/README.md
+++ b/README.md
@@ -31,7 +31,7 @@ change is atomic and transactional, git has your audit log. Each transaction
either fails or succeeds cleanly. You're entirely code centric and don't need
new infrastructure.
-
+
[](https://circleci.com/gh/fluxcd/flux)
[](https://godoc.org/github.com/fluxcd/flux)
@@ -48,7 +48,7 @@ Its major features are:
- [Automated git → cluster synchronisation](/docs/introduction.md#automated-git-cluster-synchronisation)
- [Automated deployment of new container images](/docs/introduction.md#automated-deployment-of-new-container-images)
-- [Integrations with other devops tools](/docs/introduction.md#integrations-with-other-devops-tools) ([Helm](/docs/helm/helm-integration.md) and more)
+- [Integrations with other devops tools](/docs/introduction.md#integrations-with-other-devops-tools) ([Helm](/docs/references/helm-operator-integration.md) and more)
- No additional service or infrastructure needed - Flux lives inside your
cluster
- Straight-forward control over the state of deployments in the
@@ -101,19 +101,19 @@ Get started by browsing through the documentation below:
- Background about Flux
- [Introduction to Flux](/docs/introduction.md)
- [FAQ](/docs/faq.md) and [frequently encountered issues](https://github.com/fluxcd/flux/labels/FAQ)
- - [How it works](/docs/how-it-works.md)
+ - [How it works](/docs/references/blueprint.md)
- [Considerations regarding installing Flux](/docs/install/index.md)
- - [Flux <-> Helm integration](/docs/helm/helm-integration.md)
+ - [Flux <-> Helm integration](/docs/references/helm-operator-integration.md)
- Get Started with Flux
- - [Standalone Flux](/docs/install/get-started.md)
- - [Flux using Helm](/docs/install/helm-get-started.md)
- - [Automation: annotations and locks](/docs/using/annotations-tutorial.md)
+ - [Standalone Flux](/docs/tutorials/get-started.md)
+ - [Flux using Helm](/docs/tutorials/get-started-helm.md)
+ - [Automation: annotations and locks](/docs/tutorials/driving-flux.md)
- Operating Flux
- - [Using fluxctl to control Flux](/docs/using/fluxctl.md)
- - [Helm Operator](/docs/helm/helm-operator.md)
+ - [Using fluxctl to control Flux](/docs/references/fluxctl.md)
+ - [Helm Operator](/docs/helm-operator/)
- [Troubleshooting](/docs/troubleshooting.md)
- [Frequently encountered issues](https://github.com/fluxcd/flux/labels/FAQ)
- - [Upgrading to Flux v1](/docs/using/upgrading-to-1.0.md)
+ - [Upgrading to Flux v1](/docs/guides/upgrading-to-1.0.md)
### Integrations
@@ -142,7 +142,7 @@ To familiarise yourself with the project and how things work, you might
be interested in the following:
- [Our contributions guidelines](CONTRIBUTING.md)
-- [Build documentation](/docs/development/building.md)
+- [Build documentation](/docs/contributing/building.md)
- [Release documentation](/internal_docs/releasing.md)
## <a name="help"></a>Getting Help
diff --git a/chart/flux/README.md b/chart/flux/README.md
index 568cec5ee..afdd0367b 100755
--- a/chart/flux/README.md
+++ b/chart/flux/README.md
@@ -22,7 +22,7 @@ This means fluxd can fail to apply changes to HelmRelease resources.
### Helm
Tiller should be running in the cluster, though
-[helm-operator](../../docs/helm/helm-operator.md) will wait
+[helm-operator](../../docs/helm-operator/references/operator.md) will wait
until it can find one.
# Git repo
@@ -37,7 +37,7 @@ until it can find one.
## Installation
We put together a simple [Get Started
-guide](../../docs/install/helm-get-started.md) which takes about 5-10 minutes to follow.
+guide](../../docs/tutorials/get-started-helm.md) which takes about 5-10 minutes to follow.
You will have a fully working Flux installation deploying workloads to your cluster.
## Installing Flux using Helm
@@ -154,7 +154,7 @@ The [configuration](#configuration) section lists all the parameters that can be
#### Setup Git deploy
At startup Flux generates a SSH key and logs the public key.
-Find the SSH public key by installing [fluxctl](../../docs/using/fluxctl.md) and
+Find the SSH public key by installing [fluxctl](../../docs/references/fluxctl.md) and
running:
```sh
@@ -288,8 +288,8 @@ The following tables lists the configurable parameters of the Flux chart and the
| `helmOperator.affinity` | `{}` | Affinity properties for the helmOperator deployment
| `kube.config` | [See values.yaml](/chart/flux/values.yaml#L151-L165) | Override for kubectl default config in the Flux pod(s).
| `prometheus.enabled` | `false` | If enabled, adds prometheus annotations to Flux and helmOperator pod(s)
-| `syncGarbageCollection.enabled` | `false` | If enabled, fluxd will delete resources that it created, but are no longer present in git (experimental, see [garbage collection](/docs/features/garbagecollection.md))
-| `syncGarbageCollection.dry` | `false` | If enabled, fluxd won't delete any resources, but log the garbage collection output (experimental, see [garbage collection](/docs/features/garbagecollection.md))
+| `syncGarbageCollection.enabled` | `false` | If enabled, fluxd will delete resources that it created, but are no longer present in git (experimental, see [garbage collection](/docs/references/garbagecollection.md))
+| `syncGarbageCollection.dry` | `false` | If enabled, fluxd won't delete any resources, but log the garbage collection output (experimental, see [garbage collection](/docs/references/garbagecollection.md))
Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example:
diff --git a/docs/images/deployment-pipeline.png b/docs/_files/deployment-pipeline.png
similarity index 100%
rename from docs/images/deployment-pipeline.png
rename to docs/_files/deployment-pipeline.png
diff --git a/docs/images/flux-cd-diagram.png b/docs/_files/flux-cd-diagram.png
similarity index 100%
rename from docs/images/flux-cd-diagram.png
rename to docs/_files/flux-cd-diagram.png
diff --git a/docs/images/weave-flux.png b/docs/_files/weave-flux.png
similarity index 100%
rename from docs/images/weave-flux.png
rename to docs/_files/weave-flux.png
diff --git a/docs/contributing/building.md b/docs/contributing/building.md
new file mode 100644
index 000000000..f951bbfa7
--- /dev/null
+++ b/docs/contributing/building.md
@@ -0,0 +1,33 @@
+# Building
+
+You'll need a working `go` environment version >= 1.11 (official releases are built against `1.12`).
+It's also expected that you have a Docker daemon for building images.
+
+Clone the repository. The project uses [Go Modules](https://github.com/golang/go/wiki/Modules),
+so if you explicitly define `$GOPATH` you should clone somewhere else.
+
+Then, from the root directory:
+
+```sh
+make
+```
+
+This makes Docker images, and installs binaries to `$GOBIN` (if you define it) or `$(go env GOPATH)/bin`.
+
+> **Note:** the default target architecture is amd64. If you would like
+> to try to build Docker images and binaries for a different
+> architecture you will have to set ARCH variable:
+>
+> ```sh
+> $ make ARCH=<target_arch>
+> ```
+
+## Running tests
+
+```sh
+# Unit tests
+make test
+
+# End-to-end tests
+make e2e
+```
diff --git a/docs/contributing/get-started-developing.md b/docs/contributing/get-started-developing.md
new file mode 100644
index 000000000..71ea6ac5c
--- /dev/null
+++ b/docs/contributing/get-started-developing.md
@@ -0,0 +1,287 @@
+# Get started developing
+
+This guide shows a workflow for making a small (actually, tiny) change
+to Flux, building and testing that change locally.
+
+## TL;DR
+
+From a very high level, there are at least 3 ways you can develop on
+Flux once you have your environment set up:
+
+1. The "minimalist" approach (only requires and `kubectl`):
+
+ 1. `make`
+ 2. copy the specific image tag (e.g. `docker.io/fluxcd/flux:master-a86167e4`)
+ for what you just built and paste it into `/deploy/flux-deployment.yaml`
+ as the image you're targeting to deploy
+ 3. deploy the resources in `/develop/*.yaml` manually with
+ `kubectl apply`
+ 4. make a change to the code
+ 6. see your code changes have been deployed
+ 7. repeat
+
+2. Use `freshpod` to deploy changes to the `/deploy` directory resources:
+
+ 1. `make`
+ 2. make a change to the code
+ 3. see your changes have been deployed
+ 4. repeat
+
+3. Remote cluster development approach:
+
+ 1. ensure local `kubectl` access to a remote Kubernetes cluster
+ 2. have an available local memcached instance
+ 3. make a change to the code
+ 4. ```sh
+ go run cmd/fluxd/main.go \
+ --memcached-hostname localhost \
+ --memcached-port 11211 \
+ --memcached-service "" \
+ --git-url git@github.com:fluxcd/flux-get-started \
+ --k8s-in-cluster=false
+ ```
+
+This guide covers approaches 1 and 2 using `minikube`. `freshpod` is
+superseded by `Skaffold` and is generally the future. That said,
+`freshpod` is very simple to use and reason about (and is still well
+supported by `minikube`) which is why it's used in this guide.
+
+## Run `fluxcd/flux-getting-started`
+
+We're going to make some changes soon enough, but just to get a good
+baseline please follow the ["Get started with Flux"](../tutorials/get-started.md)
+tutorial and run the `fluxcd/flux-getting-started` repo through its
+normal paces.
+
+Now that we know everything is working with `flux-getting-started`,
+we're going to try and do nearly the same thing as `flux-getting-started`,
+except instead of using official releases of flux, we're going to build
+and run what we have locally.
+
+## Prepare your environment
+
+1. Install the prerequisites. This guide is written from running Linux,
+ but the same instructions will generally apply to OSX. Although
+ everything you need has been known to work independently in Windows
+ from time to time, results may vary.
+
+ - [`minikube`](https://kubernetes.io/docs/tasks/tools/install-minikube/)
+ - [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
+ - [`docker`](https://docs.docker.com/install/)
+ - [`go`](https://golang.org/doc/install)
+
+2. Configure your environment so you can run tests. Run:
+
+ ```sh
+ make test
+ ```
+
+3. We want to make sure we're starting fresh. Tell `minikube` to clear
+ any previously running clusters:
+
+ ```sh
+ minikube delete
+ ```
+
+4. The [`minikube` addon](https://github.com/kubernetes/minikube/blob/master/docs/addons.md)
+ called [freshpod](https://github.com/GoogleCloudPlatform/freshpod)
+ that will be very useful to us later. You'll see. It's gonna be cool.
+
+ ```sh
+ minikube addons enable freshpod
+ ```
+
+5. This part is really important. You're going to set some environment
+ variables which will intercept any images pulled by docker. Run
+ `minikube docker-env` to see what we're talking about. You'll get an
+ output that shows you what the script is doing. Thankfully, it's not
+ terribly complicated - it just sets some environment variables which
+ will allow `minikube` to man-in-the-middle the requests Kubernetes
+ makes to pull images. It will look something like this:
+
+ ```sh
+ export DOCKER_TLS_VERIFY="1"
+ export DOCKER_HOST="tcp://192.168.99.128:2376"
+ export DOCKER_CERT_PATH="/home/fluxrulez/.minikube/certs"
+ export DOCKER_API_VERSION="1.35"
+ # Run this command to configure your shell:
+ # eval $(minikube docker-env)
+ ```
+
+ So, as the script suggests, run the following command:
+
+ ```sh
+ eval $(minikube docker-env)
+ ```
+
+ Now, be warned. These are local variables. This means that if you
+ run this `eval` in one terminal and then switch to another for later
+ when we build the Flux project, you're gonna hit some issues.
+ For one, you'll know it isn't working because Kubernetes will tell
+ you that it can't pull the image when you run `kubectl get pods`:
+
+ ```sh
+ NAME READY STATUS RESTARTS AGE
+ flux-7f6bd57699-shx9v 0/1 ErrImagePull 0 35s
+ ```
+
+## Prepare the repository
+
+1. Fork the [repo on GitHub](https://github.com/fluxcd/flux).
+
+2. Clone `git@github.com:<YOUR-GITHUB-USERNAME>/flux.git` replacing
+ `<YOUR-GITHUB-USERNAME>` with your GitHub username.
+
+ In the same terminal you ran `eval $(minikube docker-env)`, run
+ `GO111MODULE=on go mod download` followed by `make` from the root
+ directory of the Flux repo. You'll see docker's usual output as it
+ builds the image layers. Once it's done, you should see something
+ like this in the middle of the output:
+
+ ```sh
+ Successfully built 606610e0f4ef
+ Successfully tagged docker.io/fluxcd/flux:latest
+ Successfully tagged docker.io/fluxcd/flux:master-a86167e4
+ ```
+
+ This confirms that a new docker image was tagged for your image.
+
+3. Open up [`deploy/flux-deployment.yaml`](https://github.com/fluxcd/flux/blob/master/deploy/flux-deployment.yaml)
+ and update the image at `spec.template.spec.containers[0].image` to
+ be simply `docker.io/fluxcd/flux`. While we're here, also change
+ the `--git-url` to point towards your fork. It will look something
+ like this in the YAML:
+
+ ```yaml
+ spec:
+ template:
+ spec:
+ containers:
+ - name: flux
+ image: docker.io/fluxcd/flux
+ imagePullPolicy: IfNotPresent
+ args:
+ - --git-url=git@github.com:<YOUR-GITHUB-USERNAME>/flux-getting-started
+ - --git-branch=master
+ ```
+
+4. We're ready to apply your newly-customized deployment! Since `kubectl`
+ will apply all the Kubernetes manifests it finds (recursively) in a
+ folder, we simply need to pass the directory to `kubectl apply`:
+
+ ```sh
+ kubectl apply --filename ./deploy
+ ````
+
+ You should see an output similar to:
+
+ ```sh
+ serviceaccount/flux created
+ clusterrole.rbac.authorization.k8s.io/flux created
+ clusterrolebinding.rbac.authorization.k8s.io/flux created
+ deployment.apps/flux created
+ secret/flux-git-deploy created
+ deployment.apps/memcached created
+ service/memcached created
+ secret/flux-git-deploy configured
+ ```
+
+ Congrats you just deployed your local Flux to your default namespace.
+ Check that everything is running:
+
+ ```sh
+ kubectl get pods --selector=name=flux
+ ```
+
+ You should get an output that looks like:
+
+ ```sh
+ NAME READY STATUS RESTARTS AGE
+ flux-6f7fd5bbc-hpq85 1/1 Running 0 38s
+ ```
+
+ If (instead) you see that Ready is showing `0/1` and/or the status is
+ `ErrImagePull` double back on the instructions and make sure you did
+ everything correctly and in order.
+
+5. Pull the logs for your "fresh off of master" copy of Flux that you
+ just deployed locally to `minikube`:
+
+ ```sh
+ kubectl logs --selector=name=flux
+ ```
+
+ You should see an output that looks something like this:
+
+ ```sh
+ ts=2019-02-28T18:58:45.091531939Z caller=warming.go:268 component=warmer info="refreshing image" image=docker.io/fluxcd/flux tag_count=60 to_update=60 of_which_refresh=0 of_which_missing=60
+ ts=2019-02-28T18:58:46.233723421Z caller=warming.go:364 component=warmer updated=docker.io/fluxcd/flux successful=60 attempted=60
+ ts=2019-02-28T18:58:46.234086642Z caller=images.go:17 component=sync-loop msg="polling images"
+ ts=2019-02-28T18:58:46.234125646Z caller=images.go:27 component=sync-loop msg="no automated services"
+ ts=2019-02-28T18:58:46.749598558Z caller=warming.go:268 component=warmer info="refreshing image" image=memcached tag_count=66 to_update=66 of_which_refresh=0 of_which_missing=66
+ ts=2019-02-28T18:58:51.017452675Z caller=warming.go:364 component=warmer updated=memcached successful=66 attempted=66
+ ts=2019-02-28T18:58:51.020061586Z caller=images.go:17 component=sync-loop msg="polling images"
+ ts=2019-02-28T18:58:51.020113243Z caller=images.go:27 component=sync-loop msg="no automated services"
+ ```
+
+## Make some changes
+
+1. Now for the part you've been waiting for! We're going to make a
+ cosmetic change to our local copy of Flux. Navigate to [git/operations.go](https://github.com/fluxcd/flux/blob/master/git/operations.go).
+ In it, you will find a private function to this package that goes
+ by the name `execGitCmd`. Paste the following as the (new) first
+ line of the function:
+
+ ```go
+ fmt.Println("executing git command ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ")
+ ```
+
+2. Run `make` again. Once this finishes you can check on your running
+ pods with:
+
+ ```sh
+ kubectl get pods --selector=name=flux
+ ```
+
+ Keep your eye on the `AGE` column. It should be just a few seconds
+ old if you check out the `AGE` column:
+
+ ```sh
+ NAME READY STATUS RESTARTS AGE
+ flux-6f7fd5bbc-6j9d5 1/1 Running 0 10s
+ ```
+
+ This pod was deployed even though we didn't run any `kubectl`
+ commands or interact with Kubernetes directly because of the
+ `freshpod` `minikube` addon that we enabled earlier. Freshpod saw
+ that a new Docker image was tagged for `docker.io/fluxcd/flux:latest`
+ and it went ahead and redeployed that pod for us.
+
+ Consider that simply applying the `flux-deployment.yaml` file again
+ wouldn't do anything since the actual image we're targeting (which
+ is actually `docker.io/fluxcd/flux` with no `:latest` tag, but it's
+ the same difference) hasn't changed. The Kubernetes api server will
+ get that JSON request from `kubectl` and go: "right... so nothing has
+ changed in the file so I have nothing to do... IGNORE!".
+
+ There is another way to do this, of course. Remember that before when
+ we ran `make` that we did _also_ get an image tagged with the `:<branch>-<commit hash>`
+ syntax (in our specific example above it was `:master-a86167e4`).
+ We could, in theory, grab that tag every time we `make`, and then
+ paste it into `spec.template.spec.containers[0].image` of our
+ deployment. That's tedious and error prone. Instead, `freshpod` cuts
+ this step out for us and accomplishes the same end goal.
+
+3. Check the logs again (with `kubectl logs --selector=name=flux`) to
+ find that your obnoxious chain of `Z`s is present.
+
+## Congratulations!
+
+You have now modified Flux and deployed that change locally. From here
+on out, you simply need to run `make` after you save your changes and
+wait a few seconds for your new pod to be deployed to `minikube`.
+Keep in mind, that (as in the situation where you run `make` without
+saving any changes) if the Docker image you pointed to in the
+Kubernetes deployment for Flux is not Successfully tagged, `freshpod`
+won't have anything new to deploy.
+Other than that, you should be good to go!
diff --git a/docs/contributing/index.rst b/docs/contributing/index.rst
new file mode 100644
index 000000000..a4f190e3b
--- /dev/null
+++ b/docs/contributing/index.rst
@@ -0,0 +1,11 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Contributing
+============
+
+.. toctree::
+ :maxdepth: 1
+
+ get-started-developing
+ building
diff --git a/docs/development/building.md b/docs/development/building.md
deleted file mode 100644
index 559cc6041..000000000
--- a/docs/development/building.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Building Weave Flux
-
-You'll need a working `go` environment version >= 1.11 (official releases are built against `1.12`).
-It's also expected that you have a Docker daemon for building images.
-
-Clone the respository. The project uses Go Modules, so if you explicitly define `$GOPATH` you should
-clone somewhere else
-
-Then, from the root directory,
-
-```sh
-$ make
-```
-
-This makes Docker images, and installs binaries to `$GOBIN` (if you define it) or `$(go env GOPATH)/bin`.
-
-Note: The default target architecture is amd64. If you would like to try to build Docker images
-and binaries for a different architecture you will have to set ARCH variable,
-
-```sh
-$ make ARCH=<target_arch>
-```
-
-## Running tests
-
-```sh
-$ make test
-```
diff --git a/docs/development/get-started-developing.md b/docs/development/get-started-developing.md
deleted file mode 100644
index 0ccd7e7eb..000000000
--- a/docs/development/get-started-developing.md
+++ /dev/null
@@ -1,211 +0,0 @@
-# Get Started Developing Flux
-
-This guide shows a workflow for making a small (actually, tiny) change to Flux, building and testing that change locally.
-
-> ### TL;DR
->
-> From a very high level, there are at least 3 ways you can develop on Flux once you have your environment set up:
-> 1. The "minimalist" approach (only requires and `kubectl`):
-> 1. `make`
-> 1. copy the specific image tag (e.g. `docker.io/fluxcd/flux:master-a86167e4`) for what you just built and paste it into `/deploy/flux-deployment.yaml` as the image you're targeting to deploy
-> 1. deploy the resources in `/develop/*.yaml` manually with `kubectl apply`
-> 1. make a change to the code
-> 1. see your code changes have been deployed
-> 1. repeat
-> 1. Use `freshpod` to deploy changes to the `/deploy` directory resources:
-> 1. `make`
-> 1. make a change to the code
-> 1. see your code changes have been deployed
-> 1. repeat
-> 1. Remote cluster development approach:
-> 1. ensure local kubectl access to a remote kubernetes cluster.
-> 1. have an available local memcached instance.
-> 1. make a change to the code
-> 1. ```bash
-> go run cmd/fluxd/main.go \
-> --memcached-hostname localhost \
-> --memcached-port 11211 \
-> --memcached-service "" \
-> --git-url git@github.com:weaveworks/flux-get-started \
-> --k8s-in-cluster=false
-> ```
-> 1. repeat
-> 1. Use `helm` and `skaffold` together to deploy changes to the Flux helm chart.
-> 1. `make`
-> 1. make a change to the code
-> 1. see your code changes have been deployed
-> 1. repeat
->
-> This guide covers approaches 1 and 2 using `minikube`. `freshpod` is superseded by `Skaffold` and is generally the future. That said, `freshpod` is very simple to use and reason about (and is still well supported by `minikube`) which is why it's used in this guide.
-
-## Run `flux-getting-started`
-
-We're going to make some changes soon enough, but just to get a good baseline please follow the [Getting Started](../install/get-started.md) guide and run the `flux-getting-started` repo through its normal paces.
-
-Now that we know everything is working with `flux-getting-started`, we're going to try and do nearly the same thing as `flux-getting-started`, except instead of using official releases of flux, we're going to build and run what we have locally.
-
-## Prepare your Environment
-
-1. Install the prerequisites. This guide is written from running Linux, but the same instructions will generally apply to OSX. Although everything you need has been known to work independently in Windows from time to time, results may vary.
- - [Minikube](https://kubernetes.io/docs/tasks/tools/install-minikube/)
- - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
- - [Docker](https://docs.docker.com/install/)
- - [Go](https://golang.org/doc/install)
-
-1. Configure your enviroment so you can run tests. Run:
-
- ```sh
- make test
- ```
-
-1. We want to make sure we're starting fresh. Tell Minikube to clear any previously running clusters.
-
- ```sh
- minikube delete
- ```
-
-1. The [Minikube addon](https://github.com/kubernetes/minikube/blob/master/docs/addons.md) called [freshpod](https://github.com/GoogleCloudPlatform/freshpod) that will be very useful to us later. You'll see. It's gonna be cool.
- ```sh
- minikube addons enable freshpod
- ```
-
-1. This part is really important. You're going to set some environment variables which will intercept any images pulled by docker. Run `minikube docker-env` to see what we're talking about. You'll get an output that shows you what the script is doing. Thankfully, it's not terribly complicated - it just sets some environment variables which will allow Minikube to man-in-the-middle the requests Kubernetes makes to pull images. It will look something like this:
-
- ```sh
- export DOCKER_TLS_VERIFY="1"
- export DOCKER_HOST="tcp://192.168.99.128:2376"
- export DOCKER_CERT_PATH="/home/fluxrulez/.minikube/certs"
- export DOCKER_API_VERSION="1.35"
- # Run this command to configure your shell:
- # eval $(minikube docker-env)
- ```
-
- So, as the script suggests, run the following command:
-
- ```sh
- eval $(minikube docker-env)
- ```
-
- Now, be warned. These are local variables. This means that if you run this `eval` in one terminal and then switch to another for later when we build the Flux project, you're gonna hit some issues. For one, you'll know it isn't working because Kubernetes will tell you that it can't pull the image when you run `kubectl get pods`:
-
- ```sh
- NAME READY STATUS RESTARTS AGE
- flux-7f6bd57699-shx9v 0/1 ErrImagePull 0 35s
- ```
-
-## Prepare the Repository
-
-1. Fork the [repo on GitHub](https://github.com/weaveworks/flux).
-
-1. Clone `git@github.com:<YOUR-GITHUB-USERNAME>/flux.git` replacing `<YOUR-GITHUB-USERNAME>` with your GitHub username.
-
- In the same terminal you ran `eval $(minikube docker-env)`, run `GO111MODULE=on go mod download` followed by `make` from the root directory of the Flux repo. You'll see docker's usual output as it builds the image layers. Once it's done, you should see something like this in the middle of the output:
-
- ```sh
- Successfully built 606610e0f4ef
- Successfully tagged docker.io/fluxcd/flux:latest
- Successfully tagged docker.io/fluxcd/flux:master-a86167e4
- ```
-
- This confirms that a new docker image was tagged for your image.
-
-1. Open up [`deploy/flux-deployment.yaml`](https://github.com/weaveworks/flux/blob/master/deploy/flux-deployment.yaml) and update the image at `spec.template.spec.containers[0].image` to be simply `docker.io/weaveworks/flux`. While we're here, also change the `git-url` to point towards your fork. It will look something like this in the yaml:
-
- ```yaml
- spec:
- template:
- spec:
- containers:
- - name: flux
- image: docker.io/fluxcd/flux
- imagePullPolicy: IfNotPresent
- args:
- - --git-url=git@github.com:<YOUR-GITHUB-USERNAME>/flux-getting-started
- - --git-branch=master
- ```
-
-1. We're ready to apply your newly-customized deployment! Since `kubectl` will apply all the Kubernetes manifests it finds (recursively) in a folder, we simply need to pass the directory to `kubectl apply`
-
- ```sh
- kubectl apply --filename ./deploy
- ````
-
- You should see an output similar to:
-
- ```sh
- serviceaccount/flux created
- clusterrole.rbac.authorization.k8s.io/flux created
- clusterrolebinding.rbac.authorization.k8s.io/flux created
- deployment.apps/flux created
- secret/flux-git-deploy created
- deployment.apps/memcached created
- service/memcached created
- secret/flux-git-deploy configured
- ```
-
- Congrats you just deployed your local Flux to your default namespace. Check that everything is running:
-
- ```sh
- kubectl get pods --selector=name=flux
- ```
-
- You should get an output that looks like:
-
- ```sh
- NAME READY STATUS RESTARTS AGE
- flux-6f7fd5bbc-hpq85 1/1 Running 0 38s
- ```
-
- If (instead) you see that Ready is showing `0/1` and/or the status is `ErrImagePull` double back on the instructions and make sure you did everything correctly and in order.
-
-1. Pull the logs for your "fresh off of master" copy of Flux that you just deployed locally to Minikube:
-
- ```sh
- kubectl logs --selector=name=flux
- ```
-
- You should see an output that looks something like this:
-
- ```sh
- ts=2019-02-28T18:58:45.091531939Z caller=warming.go:268 component=warmer info="refreshing image" image=docker.io/weaveworks/flux tag_count=60 to_update=60 of_which_refresh=0 of_which_missing=60
- ts=2019-02-28T18:58:46.233723421Z caller=warming.go:364 component=warmer updated=docker.io/weaveworks/flux successful=60 attempted=60
- ts=2019-02-28T18:58:46.234086642Z caller=images.go:17 component=sync-loop msg="polling images"
- ts=2019-02-28T18:58:46.234125646Z caller=images.go:27 component=sync-loop msg="no automated services"
- ts=2019-02-28T18:58:46.749598558Z caller=warming.go:268 component=warmer info="refreshing image" image=memcached tag_count=66 to_update=66 of_which_refresh=0 of_which_missing=66
- ts=2019-02-28T18:58:51.017452675Z caller=warming.go:364 component=warmer updated=memcached successful=66 attempted=66
- ts=2019-02-28T18:58:51.020061586Z caller=images.go:17 component=sync-loop msg="polling images"
- ts=2019-02-28T18:58:51.020113243Z caller=images.go:27 component=sync-loop msg="no automated services"
- ```
-
-## Make Some Changes
-
-1. Now for the part you've been waiting for! We're going to make a cosmetic change to our local copy of Flux. Navigate to [git/operations.go](https://github.com/weaveworks/flux/blob/master/git/operations.go). In it, you will find a private function to this package that goes by the name `execGitCmd`. Paste the following as the (new) first line of the function:
-
- ```go
- fmt.Println("executing git command ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ")
- ```
-
-1. Run `make` again. Once this finishes you can check on your running pods with
-
- ```sh
- kubectl get pods --selector=name=flux
- ```
-
- Keep your eye on the `AGE` column. It should be just a few seconds old if you check out the `AGE` column:
-
- ```sh
- NAME READY STATUS RESTARTS AGE
- flux-6f7fd5bbc-6j9d5 1/1 Running 0 10s
- ```
-
- This pod was deployed even though we didn't run any `kubectl` commands or interact with Kubernetes directly because of the `freshpod` Minikube addon that we enabled earlier. Freshpod saw that a new Docker image was tagged for `docker.io/fluxcd/flux:latest` and it went ahead and redeployed that pod for us.
-
- Consider that simply applying the `flux-deployment.yaml` file again wouldn't do anything since the actual image we're targeting (which is actually `docker.io/fluxcd/flux` with no `:latest` tag, but it's the same difference) hasn't changed. The Kubernetes api server will get that JSON request from kubectl and go: "right... so nothing has changed in the file so I have nothing to do... IGNORE!".
-
- There is another way to do this, of course. Remember that before when we ran `make` that we did _also_ get an image tagged with the `:<branch>-<commit hash>` syntax (in our specific example above it was `:master-a86167e4`). We could, in theory, grab that tag every time we `make`, and then paste it into `spec.template.spec.containers[0].image` of our deployment. That's tedious and error prone. Instead, `freshpod` cuts this step out for us and accomplishes the same end goal.
-
-2. Check the logs again (with `kubectl logs --selector=name=flux`) to find that your obnoxious chain of `Z`s is present.
-
-## Congratulations!
-
-You have now modified Flux and deployed that change locally. From here on out, you simply need to run `make` after you save your changes and wait a few seconds for your new pod to be deployed to minikube. Keep in mind, that (as in the situation where you run `make` without saving any changes) if the docker image you pointed to in the Kubernetes deployment for Flux is not Successfully tagged, `freshpod` won't have anything new to deploy. Other than that, you should be good to go!
diff --git a/docs/development/index.rst b/docs/development/index.rst
deleted file mode 100644
index 7a39bb441..000000000
--- a/docs/development/index.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-.. Flux documentation documentation master file, created by
- sphinx-quickstart on Wed Jun 12 16:13:18 2019.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Developing the Flux codebase
-==============================================
-
-.. toctree::
- :maxdepth: 2
- :caption: Contents:
-
-
- get-started-developing
- building
diff --git a/docs/faq.md b/docs/faq.md
index 6453a2444..46e90a7d7 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -1,4 +1,4 @@
-# Flux FAQ
+# Frequently asked questions
## General questions
@@ -49,9 +49,7 @@ example. We may return to the matter of staged deployments.
### Are there prerelease builds I can run?
There are builds from CI for each merge to master branch. See
-[weaveworks/flux-prerelease](https://hub.docker.com/r/weaveworks/flux-prerelease/tags)
-and
-[weaveworks/helm-operator-prerelease](https://hub.docker.com/r/weaveworks/helm-operator-prerelease/tags).
+[fluxcd/flux-prerelease](https://hub.docker.com/r/fluxcd/flux-prerelease/tags).
## Technical questions
@@ -65,7 +63,7 @@ application code as you like, to be clear -- see
There's no principled reason for this, it's just
a consequence of time and effort being in finite supply. If you have a
use for multiple git repo support, please comment in
-https://github.com/weaveworks/flux/issues/1164.
+https://github.com/fluxcd/flux/issues/1164.
In the meantime, for some use cases you can run more than one Flux
daemon and point them at different repos. If you do this, consider
@@ -107,7 +105,7 @@ fluxctl release --controller=deployment/foo --update-image=bar:v2
The image tag will be updated in the git repository upon applying the command.
-For more information about Flux commands see [the fluxctl docs](./using/fluxctl.md).
+For more information about Flux commands see [the `fluxctl` docs](references/fluxctl.md).
### Does Flux automatically sync changes back to git?
@@ -117,13 +115,13 @@ No. It applies changes to git only when a Flux command or API call makes them.
Flux has an experimental (for now) garbage collection feature,
enabled by passing the command-line flag `--sync-garbage-collection`
-to fluxd.
+to `fluxd`.
The garbage collection is conservative: it is designed to not delete
-resources that were not created by fluxd. This means it will sometimes
-_not_ delete resources that _were_ created by fluxd, when
+resources that were not created by `fluxd`. This means it will sometimes
+_not_ delete resources that _were_ created by `fluxd`, when
reconfigured. Read more about garbage collection
-[here](./features/garbagecollection.md).
+[here](references/garbagecollection.md).
### How do I give Flux access to an image registry?
@@ -148,7 +146,7 @@ There are exceptions:
To work around exceptional cases, you can mount a docker config into
the Flux container. See the argument `--docker-config` in [the daemon
-arguments reference](./features/daemon.md).
+arguments reference](references/daemon.md).
See also
[Why are my images not showing up in the list of images?](#why-are-my-images-not-showing-up-in-the-list-of-images)
@@ -169,7 +167,7 @@ registries if you spam them with requests.
If you are using GCP/GKE/GCR, you will likely want much lower rate
limits. Please see
-[weaveworks/flux#1016](https://github.com/weaveworks/flux/issues/1016)
+[fluxcd/flux#1016](https://github.com/fluxcd/flux/issues/1016)
for specific advice.
### How often does Flux check for new git commits (and can I make it sync faster)?
@@ -211,7 +209,7 @@ Then create a new secret named `flux-git-deploy`, using your private key as the
`kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/private_key`
-Now restart fluxd to re-read the k8s secret (if it is running):
+Now restart `fluxd` to re-read the k8s secret (if it is running):
`kubectl delete $(kubectl get pod -o name -l name=flux)`
@@ -231,7 +229,7 @@ service, or running your own git host, you need to supply your own
host key(s).
How to do this is documented in
-[the standalone setup doc](./install/standalone-setup.md).
+["Using a private Git host"](./guides/use-private-git-host.md).
### Why does my CI pipeline keep getting triggered?
@@ -279,7 +277,7 @@ attempts to scan for workloads.
### Can I change the namespace Flux puts things in by default?
-Yes. The fluxd image has a "kubeconfig" file baked in, which specifies
+Yes. The `fluxd` image has a "kubeconfig" file baked in, which specifies
a default namespace of `"default"`. That means any manifest not
specifying a namespace (in `.metadata.namespace`) will be given the
namespace `"default"` when applied to the cluster.
@@ -287,12 +285,12 @@ namespace `"default"` when applied to the cluster.
You can override this by mounting your own "kubeconfig" file into the
container from a configmap, and using the `KUBECONFIG` environment
entry to point to it. The [example
-deployment](https://github.com/weaveworks/flux/blob/master/deploy/flux-deployment.yaml) shows how to do this, in
+deployment](https://github.com/fluxcd/flux/blob/master/deploy/flux-deployment.yaml) shows how to do this, in
commented out sections -- it needs extra bits of config in three
places (the `volume`, `volumeMount`, and `env` entries).
The easiest way to create a suitable "kubeconfig" will be to adapt the
-[file that is baked into the image](https://github.com/weaveworks/flux/blob/master/docker/kubeconfig). Save that
+[file that is baked into the image](https://github.com/fluxcd/flux/blob/master/docker/kubeconfig). Save that
locally as `my-kubeconfig`, edit it to change the default namespace,
then create the configmap, in the same namespace you run Flux in, with
something like:
@@ -323,7 +321,7 @@ Sometimes it might be easier to annotate a *running resource in
the cluster* as opposed to committing a change to git. Please note
that this will only work with resources of the type `namespace`
and the set of controllers in
-[resourcekinds.go](https://github.com/weaveworks/flux/blob/master/cluster/kubernetes/resourcekinds.go),
+[resourcekinds.go](https://github.com/fluxcd/flux/blob/master/cluster/kubernetes/resourcekinds.go),
namely `deployment`, `daemonset`, `cronjob`, `statefulset` and
`fluxhelmrelease`).
@@ -336,7 +334,7 @@ kubectl annotate <resource> "flux.weave.works/ignore"-
Mixing both kinds of annotations (in-git and in-cluster), can make
it a bit hard to figure out how/where to undo the change (cf
-[flux#1211](https://github.com/weaveworks/flux/issues/1211)).
+[flux#1211](https://github.com/fluxcd/flux/issues/1211)).
The full story is this: Flux looks at the files and the running
resources when deciding whether what to apply. But it gets the
@@ -386,44 +384,5 @@ Flux experimentally supports technology-agnostic manifest factorization through
`.flux.yaml` configuration files placed in the Git repository. To enable this
feature please supply `fluxd` with flag `--manifest-generation=true`.
-See [`.flux.yaml` configuration files documentation](./features/fluxyaml-config-files.md) for
+See [`.flux.yaml` configuration files documentation](references/fluxyaml-config-files.md) for
further details.
-
-## Flux Helm Operator questions
-
-### I'm using SSL between Helm and Tiller. How can I configure Flux to use the certificate?
-
-When installing Flux, you can supply the CA and client-side certificate using the `helmOperator.tls` options,
-more details [here](https://github.com/weaveworks/flux/blob/master/chart/flux/README.md#installing-weave-flux-helm-operator-and-helm-with-tls-enabled).
-
-### I've deleted a HelmRelease file from Git. Why is the Helm release still running on my cluster?
-
-Flux doesn't delete resources, there is an [issue](https://github.com/weaveworks/flux/issues/738) opened about this topic on GitHub.
-In order to delete a Helm release first remove the file from Git and afterwards run:
-
-```yaml
-kubectl delete helmrelease/my-release
-```
-
-The Flux Helm operator will receive the delete event and will purge the Helm release.
-
-### I've manually deleted a Helm release. Why is Flux not able to restore it?
-
-If you delete a Helm release with `helm delete my-release`, the release name can't be reused.
-You need to use the `helm delete --purge` option only then Flux will be able reinstall a release.
-
-### I have a dedicated Kubernetes cluster per environment and I want to use the same Git repo for all. How can I do that?
-
-*Option 1*
-For each cluster create a directory in your config repo.
-When installing Flux Helm chart set the Git path using `--set git.path=k8s/cluster-name`
-and set a unique label for each cluster `--set git.label=cluster-name`.
-
-You can have one or more shared dirs between clusters. Assuming your shared dir is located
-at `k8s/common` set the Git path as `--set git.path="k8s/common\,k8s/cluster-name"`.
-
-*Option 2*
-For each cluster create a Git branch in your config repo.
-When installing Flux Helm chart set the Git branch using `--set git.branch=cluster-name`
-and set a unique label for each cluster `--set git.label=cluster-name`.
-
diff --git a/docs/features/index.rst b/docs/features/index.rst
deleted file mode 100644
index 3ffca535b..000000000
--- a/docs/features/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. Flux documentation documentation master file, created by
- sphinx-quickstart on Wed Jun 12 16:13:18 2019.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-
-Flux Features
-==============================================
-
-.. toctree::
- :maxdepth: 1
- :caption: Contents:
-
- daemon
- fluxyaml-config-files
- garbagecollection
diff --git a/docs/install/index.rst b/docs/get-started/index.rst
similarity index 52%
rename from docs/install/index.rst
rename to docs/get-started/index.rst
index a2400b939..4de102604 100644
--- a/docs/install/index.rst
+++ b/docs/get-started/index.rst
@@ -1,28 +1,19 @@
-======================
-Prerequisites for Flux
-======================
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Get started
+===========
All you need is a Kubernetes cluster and a git repo. The git repo
contains `manifests <https://kubernetes.io/docs/concepts/configuration/overview/>`_
(as YAML files) describing what should run in the cluster. Flux imposes
:doc:`some requirements <../requirements>` on these files.
-Installing Weave Flux
-=====================
+Installing Flux
+---------------
Here are the instructions to :doc:`install Flux on your own
-cluster <./get-started>`.
+cluster <../tutorials/get-started>`.
If you are using Helm, we have a :doc:`separate section about
-this <./helm-get-started>`.
-
-You can also configure a more advanced, :doc:`standalone
-setup <./standalone-setup>`.
-
-.. toctree::
- :maxdepth: 1
- :caption: Contents:
-
- get-started
- helm-get-started
- standalone-setup
+this <../tutorials/get-started-helm>`.
diff --git a/docs/guides/index.rst b/docs/guides/index.rst
new file mode 100644
index 000000000..00f15501d
--- /dev/null
+++ b/docs/guides/index.rst
@@ -0,0 +1,12 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Guides
+======
+
+.. toctree::
+ :maxdepth: 1
+
+ provide-own-ssh-key
+ use-private-git-host
+ upgrading-to-1.0
diff --git a/docs/guides/provide-own-ssh-key.md b/docs/guides/provide-own-ssh-key.md
new file mode 100644
index 000000000..d747533aa
--- /dev/null
+++ b/docs/guides/provide-own-ssh-key.md
@@ -0,0 +1,36 @@
+# Providing your own SSH key
+
+Flux connects to the repository using an SSH key it retrieves from a
+Kubernetes secret, if the configured (`--k8s-secret-name`) secret has
+no `identity` key/value pair, it will generate new private key.
+
+With this knowledge, providing your own SSH key is as simple as
+creating the configured secret in the expected format.
+
+1. create a Kubernetes secret from your own private key:
+
+ ```sh
+ kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/private_key
+ ```
+
+ this will result in a secret that has the structure:
+
+ ```yaml
+ apiVersion: v1
+ data:
+ identity: <base64 encoded RSA PRIVATE KEY>
+ kind: Secret
+ type: Opaque
+ metadata:
+ ...
+ ```
+
+2. _(optional)_ if you created the secret with a non-default name
+ (default: `flux-git-deploy`), set the `--k8s-secret-name` flag to
+ the name of your secret (i.e. `--k8s-secret-name=foo`).
+
+> **Note:** the SSH key must be configured to have R/W access to the
+> repository. More specifically, the SSH key must be able to create
+> and update tags. E.g. in Gitlab, that means it requires `Maintainer`
+> permissions. The `Developer` permission can create tags, but not
+> update them.
diff --git a/docs/using/upgrading-to-1.0.md b/docs/guides/upgrading-to-1.0.md
similarity index 89%
rename from docs/using/upgrading-to-1.0.md
rename to docs/guides/upgrading-to-1.0.md
index 163e993be..86706e293 100644
--- a/docs/using/upgrading-to-1.0.md
+++ b/docs/guides/upgrading-to-1.0.md
@@ -8,7 +8,7 @@ service. This meant that to get a useful system, you had to run both
the daemon and the service in your cluster. In version 1, the daemon
does all of the mechanical work by itself.
-## Differences between Old Flux and Flux v1
+## Differences between old Flux and Flux v1
In version 1 the daemon is more self-sufficient and easier to set
up. It is also more capable, and in particular, it now synchronises
@@ -81,9 +81,9 @@ First, it will help in a few places to have an old fluxctl
around. Download it from GitHub:
```sh
-curl -o fluxctl_030 https://github.com/weaveworks/flux/releases/download/0.3.0/fluxctl_linux_amd64
+curl -o fluxctl_030 https://github.com/fluxcd/flux/releases/download/0.3.0/fluxctl_linux_amd64
# or if using macOS,
-# curl -o fluxctl_030 https://github.com/weaveworks/flux/releases/download/0.3.0/fluxctl_darwin_amd64
+# curl -o fluxctl_030 https://github.com/fluxcd/flux/releases/download/0.3.0/fluxctl_darwin_amd64
chmod a+x ./fluxctl_030
```
@@ -91,7 +91,7 @@ chmod a+x ./fluxctl_030
Set the environment variable FLUX_URL to point to the Flux service you
are running, as described in
-[the old deployment docs](https://github.com/weaveworks/flux/blob/0.3.0/site/using.md#fluxctl-setup). The
+[the old deployment docs](https://github.com/fluxcd/flux/blob/0.3.0/site/using.md#fluxctl-setup). The
particular URL will differ, depending on how you have told Kubernetes
to expose the Flux service.
@@ -115,7 +115,7 @@ used to create them. If you don’t have the files on hand, you can try
using the example deployment as a stand-in:
```sh
-git clone --branch 0.3.0 git@github.com:weaveworks/flux flux-0.3.0
+git clone --branch 0.3.0 git@github.com:fluxcd/flux flux-0.3.0
kubectl delete --ignore-not-found -R -f ./flux-0.3.0/deploy
```
@@ -139,7 +139,7 @@ by Flux in the file `old-config.yaml` that was created earlier.
To run Flux without connecting to Weave Cloud, adapt the manifests
provided in the
-[Flux repo](https://github.com/weaveworks/flux/tree/master/deploy)
+[Flux repo](https://github.com/fluxcd/flux/tree/master/deploy)
with the git parameters (URL, path, and branch) from
`old-config.yaml`, and then apply them with `kubectl`. Consider adding
these adapted manifests to your own config repo.
@@ -150,11 +150,11 @@ just that).
You may find that you need to set FLUX_URL again, to take account of
the new deployment. See the
-[setup instructions](https://github.com/weaveworks/flux/blob/1.0.1/site/standalone/setup.md#connecting-fluxctl-to-the-daemon)
+[setup instructions](https://github.com/fluxcd/flux/blob/1.0.1/site/standalone/setup.md#connecting-fluxctl-to-the-daemon)
for guidance.
To see the SSH key created by Flux, download the latest fluxctl from
-[the release page](https://github.com/weaveworks/flux/releases/tag/1.0.1)
+[the release page](https://github.com/fluxcd/flux/releases/tag/1.0.1)
and run:
```sh
diff --git a/docs/guides/use-private-git-host.md b/docs/guides/use-private-git-host.md
new file mode 100644
index 000000000..5f1524fc5
--- /dev/null
+++ b/docs/guides/use-private-git-host.md
@@ -0,0 +1,87 @@
+# Using a private Git host
+
+If you're using your own git host -- e.g., your own installation of
+gitlab, or bitbucket server -- you will need to add its host key to
+`~/.ssh/known_hosts` in the Flux daemon container.
+
+First, run a check that you can clone the repo. The following assumes
+that your git server's hostname (e.g., `githost`) is in `$GITHOST` and
+the URL you'll use to access the repository (e.g.,
+`user@githost:path/to/repo`) is in `$GITREPO`.
+
+```sh
+$ # Find the fluxd daemon pod:
+$ kubectl get pods --all-namespaces -l name=flux
+NAMESPACE NAME READY STATUS RESTARTS AGE
+weave flux-85cdc6cdfc-n2tgf 1/1 Running 0 1h
+
+$ kubectl exec -n weave flux-85cdc6cdfc-n2tgf -ti -- \
+ env GITHOST="$GITHOST" GITREPO="$GITREPO" PS1="container$ " /bin/sh
+
+container$ git clone $GITREPO
+Cloning into <repository name>...
+No ECDSA host key is known for <GITHOST> and you have requested strict checking.
+Host key verification failed.
+fatal: Could not read from remote repository
+
+container$ # ^ that was expected. Now we'll try with a modified known_hosts
+container$ ssh-keyscan $GITHOST >> ~/.ssh/known_hosts
+container$ git clone $GITREPO
+Cloning into '...'
+...
+```
+
+If `git clone` doesn't succeed, you'll need to check that the SSH key
+has been installed properly first, then come back. `ssh -vv $GITHOST`
+from within the container may help debug it.
+
+If it _did_ work, you will need to make it a more permanent
+arrangement. Back in that shell, create a ConfigMap for the cluster. To
+make sure the ConfigMap is created in the namespace of the Flux
+deployment, the namespace is set explicitly:
+
+```sh
+container$ kubectl create configmap flux-ssh-config --from-file=$HOME/.ssh/known_hosts -n $(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
+configmap "flux-ssh-config" created
+```
+
+To use the ConfigMap every time the Flux daemon restarts, you'll need
+to mount it into the container. The example deployment manifest
+includes an example of doing this, commented out. Uncomment those two blocks:
+
+```yaml
+ - name: ssh-config
+ configMap:
+ name: flux-ssh-config
+```
+
+```yaml
+ - name: ssh-config
+ mountPath: /root/.ssh
+```
+
+It assumes you used `flux-ssh-config` as name of the ConfigMap and then reapply the
+manifest.
+
+Another alternative is to create the ConfigMap from a template. This could be
+something like:
+
+```yaml
+apiVersion: v1
+data:
+ known_hosts: |
+ # github
+ 192.30.253.112 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
+ # github
+ 192.30.253.113 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
+ # private gitlab
+ gitlab.________ ssh-rsa AAAAB3N...
+kind: ConfigMap
+metadata:
+ name: flux-ssh-config
+ namespace: <OPTIONAL NAMESPACE (if not default)>
+```
+
+You will need to explicitly tell `fluxd` to use that service account by
+uncommenting and possible adapting the line `# serviceAccountName:
+flux` in the file `flux-deployment.yaml` before applying it.
diff --git a/docs/helm-operator/faq.md b/docs/helm-operator/faq.md
new file mode 100644
index 000000000..741372df4
--- /dev/null
+++ b/docs/helm-operator/faq.md
@@ -0,0 +1,42 @@
+# Frequently asked questions
+
+### I'm using SSL between Helm and Tiller. How can I configure Flux to use the certificate?
+
+When installing Flux, you can supply the CA and client-side certificate using the `helmOperator.tls` options,
+more details [here](https://github.com/fluxcd/flux/blob/master/chart/flux/README.md#installing-weave-flux-helm-operator-and-helm-with-tls-enabled).
+
+### I've deleted a HelmRelease file from Git. Why is the Helm release still running on my cluster?
+
+Flux doesn't delete resources, there is an [issue](https://github.com/fluxcd/flux/issues/738) opened about this topic on GitHub.
+In order to delete a Helm release first remove the file from Git and afterwards run:
+
+```yaml
+kubectl delete helmrelease/my-release
+```
+
+The Helm operator will receive the delete event and will purge the Helm release.
+
+### I've manually deleted a Helm release. Why is Flux not able to restore it?
+
+If you delete a Helm release with `helm delete my-release`, the release name can't be reused.
+You need to use the `helm delete --purge` option only then Flux will be able reinstall a release.
+
+### I have a dedicated Kubernetes cluster per environment and I want to use the same Git repo for all. How can I do that?
+
+*Option 1*
+For each cluster create a directory in your config repo.
+When installing Flux Helm chart set the Git path using `--set git.path=k8s/cluster-name`
+and set a unique label for each cluster `--set git.label=cluster-name`.
+
+You can have one or more shared dirs between clusters. Assuming your shared dir is located
+at `k8s/common` set the Git path as `--set git.path="k8s/common\,k8s/cluster-name"`.
+
+*Option 2*
+For each cluster create a Git branch in your config repo.
+When installing Flux Helm chart set the Git branch using `--set git.branch=cluster-name`
+and set a unique label for each cluster `--set git.label=cluster-name`.
+
+### Are there prerelease builds I can run?
+
+There are builds from CI for each merge to master branch. See
+[fluxcd/helm-operator-prerelease](https://hub.docker.com/r/fluxcd/helm-operator-prerelease/tags).
diff --git a/docs/helm-operator/guides/index.rst b/docs/helm-operator/guides/index.rst
new file mode 100644
index 000000000..1dd0c6674
--- /dev/null
+++ b/docs/helm-operator/guides/index.rst
@@ -0,0 +1,10 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Guides
+======
+
+.. toctree::
+ :maxdepth: 1
+
+ upgrading-to-beta
diff --git a/docs/helm/helm-upgrading-to-beta.md b/docs/helm-operator/guides/upgrading-to-beta.md
similarity index 96%
rename from docs/helm/helm-upgrading-to-beta.md
rename to docs/helm-operator/guides/upgrading-to-beta.md
index 87a7c04a3..7270adb2f 100644
--- a/docs/helm/helm-upgrading-to-beta.md
+++ b/docs/helm-operator/guides/upgrading-to-beta.md
@@ -43,7 +43,7 @@ helm upgrade flux --reuse-values \
--set image.tag=1.8.1 \
--set helmOperator.tag=0.5.1 \
--namespace=flux \
-weaveworks/flux --version 0.5.1
+fluxcd/flux --version 0.5.1
```
The chart will leave the old custom resource definition and custom
@@ -72,8 +72,8 @@ since it expects the SSH key for the git repo to be in the same place.
Once you want to use the new capabilities of the operator -- e.g.,
releasing charts from Helm repos -- you will probably need to adapt
the manifest further. The [Helm operator set-up
-guide](./helm-integration.md) and [example
-deployment](https://github.com/weaveworks/flux/blob/master/deploy-helm/helm-operator-deployment.yaml)
+guide](../../references/helm-operator-integration.md) and [example
+deployment](https://github.com/fluxcd/flux/blob/master/deploy-helm/helm-operator-deployment.yaml)
explain all the details.
## Updating custom resources
diff --git a/docs/helm-operator/index.rst b/docs/helm-operator/index.rst
new file mode 100644
index 000000000..9eac5cdd7
--- /dev/null
+++ b/docs/helm-operator/index.rst
@@ -0,0 +1,15 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Helm operator
+=============
+
+.. toctree::
+ :maxdepth: 2
+
+ references/index
+ guides/index
+ tutorials/index
+
+ faq
+ troubleshooting
diff --git a/docs/helm/helm-integration.md b/docs/helm-operator/references/helmrelease-custom-resource.md
similarity index 72%
rename from docs/helm/helm-integration.md
rename to docs/helm-operator/references/helmrelease-custom-resource.md
index 930dfa5e6..eb8a4de1e 100644
--- a/docs/helm/helm-integration.md
+++ b/docs/helm-operator/references/helmrelease-custom-resource.md
@@ -1,25 +1,11 @@
-# Using Flux with Helm
-
-You can release charts to your cluster via "GitOps", by combining Flux
-and the Flux Helm Operator (also in
-[weaveworks/flux](https://github.com/weaveworks/flux)).
-
-The essential mechanism is this: the declaration of a Helm release is
-represented by a custom resource, specifying the chart and its
-values. If you put such a resource in your git repo as a file, Flux
-will apply it to the cluster, and once it's in the cluster, the Helm
-Operator will make sure the release exists by installing or upgrading
-it.
-
-## The `HelmRelease` custom resource
+# `HelmRelease` Custom Resource
Each release of a chart is declared by a `HelmRelease`
resource. The schema for these resources is given in [the custom
-resource definition](https://github.com/weaveworks/flux/blob/master/deploy-helm/flux-helm-release-crd.yaml). They
+resource definition](https://github.com/fluxcd/flux/blob/master/deploy-helm/flux-helm-release-crd.yaml). They
look like this:
```yaml
----
apiVersion: flux.weave.works/v1beta1
kind: HelmRelease
metadata:
@@ -52,7 +38,17 @@ The `values` section is where you provide the value overrides for the
chart. This is as you would put in a `values.yaml` file, but inlined
into the structure of the resource. See below for examples.
-### Using a chart from a Git repo instead of a Helm repo
+<a name="why-repo-urls">**Why use URLs to refer to repositories, rather than names?**</a> [^](#cite-why-repo-urls)
+
+A `HelmRelease` must be able to stand on its own. If we used names
+in the spec, which were resolved to URLs elsewhere (e.g., in a
+`repositories.yaml` supplied to the operator), it would be possible to
+change the meaning of a `HelmRelease` without altering it. This is
+undesirable because it makes it hard to specify exactly what you want,
+in the one place; or to read exactly what is being specified, in the
+one place. In other words, it's better to be explicit.
+
+## Using a chart from a Git repo instead of a Helm repo
You can refer to a chart from a _git_ repo, rather than a chart repo,
with a `chart:` section like this:
@@ -60,7 +56,7 @@ with a `chart:` section like this:
```yaml
spec:
chart:
- git: git@github.com:weaveworks/flux-get-started
+ git: git@github.com:fluxcd/flux-get-started
ref: master
path: charts/ghost
```
@@ -76,7 +72,7 @@ secret at the expected location of the key (`/etc/fluxd/ssh/`). If you
need more than one SSH key, you'll need to also mount an adapted
ssh_config; this is also demonstrated in the example deployment.
-#### Notifying Helm Operator about Git changes
+### Notifying Helm Operator about Git changes
The Helm Operator fetches the upstream of mirrored Git repositories
with a 5 minute interval. In some scenarios (think CI/CD), you may not
@@ -95,29 +91,6 @@ OK
> either need to port forward before making the request or put something
> in front of it to serve as a gatekeeper.
-### Reinstalling a Helm release
-
-If a Helm release upgrade fails due to incompatible changes like modifying
-an immutable field (e.g. headless svc to ClusterIP)
-you can reinstall it using the following command:
-
-```sh
-$ kubectl delete hr/my-release
-```
-
-When the Helm Operator receives a delete event from Kubernetes API it will
-call Tiller and purge the Helm release. On the next Flux sync, the Helm Release
-object will be created and the Helm Operator will install it.
-
-### What the Helm Operator does
-
-When the Helm Operator sees a `HelmRelease` resource in the
-cluster, it either installs or upgrades the named Helm release so that
-the chart is released as specified.
-
-It will also notice when a `HelmRelease` resource is updated, and
-take action accordingly.
-
## Supplying values to the chart
You can supply values to be used with the chart when installing it, in
@@ -219,130 +192,6 @@ spec:
optional: true # optional; defaults to false
```
-## Upgrading images in a `HelmRelease` using Flux
-
-If the chart you're using in a `HelmRelease` lets you specify the
-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`.
-
-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):
-
-```yaml
-values:
- image: repo/image:version
-```
-
-```yaml
-values:
- image: repo/image
- tag: version
-```
-
-```yaml
-values:
- registry: docker.io
- image: repo/image
- tag: version
-```
-
-```yaml
-values:
- image:
- repository: repo/image
- tag: version
-```
-
-```yaml
-values:
- image:
- registry: docker.io
- repository: repo/image
- tag: version
-```
-
-These can appear at the top level (immediately under `values:`), or in
-a subsection (under a key, itself under `values:`). Other values
-may be mixed in arbitrarily. Here's an example of a values section
-that specifies two images, along with some other configuration:
-
-```yaml
-values:
- persistent: true
-
- # image that will be labeled "chart-image"
- image: repo/image1:version
-
- subsystem:
- # image that will be labeled "subsystem"
- image:
- repository: repo/image2
- tag: version
- imagePullPolicy: IfNotPresent
- port: 4040
-```
-
-You can use the [same annotations](../using/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).
-
-Top level image example:
-
-```yaml
-kind: HelmRelease
-metadata:
- annotations:
- flux.weave.works/automated: "true"
- flux.weave.works/tag.chart-image: semver:~4.0
-spec:
- values:
- image:
- repository: bitnami/mongodb
- tag: 4.0.3
-```
-
-Sub-section images example:
-
-```yaml
-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.*
-spec:
- values:
- prometheus:
- image: prom/prometheus:v2.3.1
- alertmanager:
- image: prom/alertmanager:v0.15.0
- nats:
- image:
- repository: nats-streaming
- tag: 0.6.0
-```
-
--------------
-
-<a name="why-repo-urls">**Why use URLs to refer to repositories, rather than names?**</a> [^](#cite-why-repo-urls)
-
-A `HelmRelease` must be able to stand on its own. If we used names
-in the spec, which were resolved to URLs elsewhere (e.g., in a
-`repositories.yaml` supplied to the operator), it would be possible to
-change the meaning of a `HelmRelease` without altering it. This is
-undesirable because it makes it hard to specify exactly what you want,
-in the one place; or to read exactly what is being specified, in the
-one place. In other words, it's better to be explicit.
-
## Rollbacks
From time to time a release made by the Helm operator may fail, it is
@@ -384,6 +233,20 @@ spec:
wait: false
```
+## Reinstalling a Helm release
+
+If a Helm release upgrade fails due to incompatible changes like modifying
+an immutable field (e.g. headless svc to ClusterIP)
+you can reinstall it using the following command:
+
+```sh
+$ kubectl delete hr/my-release
+```
+
+When the Helm Operator receives a delete event from Kubernetes API it will
+call Tiller and purge the Helm release. On the next Flux sync, the Helm Release
+object will be created and the Helm Operator will install it.
+
## Authentication
At present, per-resource authentication is not implemented. The
@@ -400,7 +263,7 @@ As a workaround, you can mount a `repositories.yaml` file with
authentication already configured, into the operator container.
> **Note:** When using a custom `repositories.yaml` the
-[default](https://github.com/weaveworks/flux/blob/master/docker/helm-repositories.yaml)
+[default](https://github.com/fluxcd/flux/blob/master/docker/helm-repositories.yaml)
that ships with the operator is overwritten. This means that for any
repository you want to make use of you should manually add an entry to
your `repositories.yaml` file.
@@ -431,7 +294,7 @@ kubectl create secret generic flux-helm-repositories --from-file=./repositories.
Lastly, mount that secret into the container. This can be done by
setting `helmOperator.configureRepositories.enable` to `true` for the
flux Helm release, or as shown in the commented-out sections of the
-[example deployment](https://github.com/weaveworks/flux/blob/master/deploy-helm/helm-operator-deployment.yaml).
+[example deployment](https://github.com/fluxcd/flux/blob/master/deploy-helm/helm-operator-deployment.yaml).
#### Azure ACR repositories
@@ -460,7 +323,7 @@ access.
To provide an SSH key, put the key in a secret under the entry
`identity`, and mount it into the operator container as shown in the
-[example deployment](https://github.com/weaveworks/flux/blob/master/deploy-helm/helm-operator-deployment.yaml).
+[example deployment](https://github.com/fluxcd/flux/blob/master/deploy-helm/helm-operator-deployment.yaml).
The default ssh_config expects an identity file at
`/etc/fluxd/ssh/identity`, which is where it'll be if you just
uncomment the blocks from the example.
diff --git a/docs/helm-operator/references/index.rst b/docs/helm-operator/references/index.rst
new file mode 100644
index 000000000..092ec1169
--- /dev/null
+++ b/docs/helm-operator/references/index.rst
@@ -0,0 +1,11 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+References
+==========
+
+.. toctree::
+ :maxdepth: 1
+
+ operator
+ helmrelease-custom-resource
diff --git a/docs/helm-operator/references/operator.md b/docs/helm-operator/references/operator.md
new file mode 100644
index 000000000..02a73d8d0
--- /dev/null
+++ b/docs/helm-operator/references/operator.md
@@ -0,0 +1,40 @@
+# Helm operator (`helm-operator`)
+
+The Helm operator deals with Helm chart releases. The operator watches for
+changes of Custom Resources of kind `HelmRelease`. It receives Kubernetes
+Events and acts accordingly.
+
+## Responsibilities
+
+When the Helm Operator sees a `HelmRelease` resource in the
+cluster, it either installs or upgrades the named Helm release so that
+the chart is released as specified.
+
+It will also notice when a `HelmRelease` resource is updated, and
+take action accordingly.
+
+## Setup and configuration
+
+`helm-operator` requires setup and offers customization though a multitude of flags.
+
+| flag | default | purpose
+| ------------------------ | ----------------------------- | ---
+| --kubeconfig | | Path to a kubeconfig. Only required if out-of-cluster.
+| --master | | The address of the Kubernetes API server. Overrides any value in kubeconfig. Only required if out-of-cluster.
+| --allow-namespace | | If set, this limits the scope to a single namespace. if not specified, all namespaces will be watched.
+| **Tiller options**
+| --tiller-ip | | Tiller IP address. Only required if out-of-cluster.
+| --tiller-port | | Tiller port.
+| --tiller-namespace | | Tiller namespace. If not provided, the default is kube-system.
+| --tiller-tls-enable | `false` | Enable TLS communication with Tiller. If provided, requires TLSKey and TLSCert to be provided as well.
+| --tiller-tls-verify | `false` | Verify TLS certificate from Tiller. Will enable TLS communication when provided.
+| --tiller-tls-key-path | `/etc/fluxd/helm/tls.key` | Path to private key file used to communicate with the Tiller server.
+| --tiller-tls-cert-path | `/etc/fluxd/helm/tls.crt` | Path to certificate file used to communicate with the Tiller server.
+| --tiller-tls-ca-cert-path | | Path to CA certificate file used to validate the Tiller server. Required if tiller-tls-verify is enabled.
+| --tiller-tls-hostname | | The server name used to verify the hostname on the returned certificates from the Tiller server.
+| **repo chart changes** (none of these need overriding, usually)
+| --charts-sync-interval | `3m` | Interval at which to check for changed charts.
+| --git-timeout | `20s` | Duration after which git operations time out.
+| --git-poll-interval | `5m` | Period on which to poll git chart sources for changes.
+| --log-release-diffs | `false` | Log the diff when a chart release diverges. **Potentially insecure.**
+| --update-chart-deps | `true` | Update chart dependencies before installing or upgrading a release.
diff --git a/docs/helm-operator/troubleshooting.md b/docs/helm-operator/troubleshooting.md
new file mode 100644
index 000000000..9a9d2f78b
--- /dev/null
+++ b/docs/helm-operator/troubleshooting.md
@@ -0,0 +1,27 @@
+# Troubleshooting
+
+Also see the [issues labeled with
+`FAQ`](https://github.com/fluxcd/flux/labels/FAQ), which often
+explain workarounds.
+
+## Error creating helm client: failed to append certificates from file: /etc/fluxd/helm-ca/ca.crt
+
+Your CA certificate content is not set correctly, check if your ConfigMap contains the correct values. Example:
+
+```bash
+$ kubectl get configmaps flux-helm-tls-ca-config -o yaml
+apiVersion: v1
+data:
+ ca.crt: |
+ -----BEGIN CERTIFICATE-----
+ ....
+ -----END CERTIFICATE-----
+kind: ConfigMap
+metadata:
+ creationTimestamp: 2018-07-04T15:27:25Z
+ name: flux-helm-tls-ca-config
+ namespace: helm-system
+ resourceVersion: "1267257"
+ selfLink: /api/v1/namespaces/helm-system/configmaps/flux-helm-tls-ca-config
+ uid: c106f866-7f9e-11e8-904a-025000000001
+```
diff --git a/docs/helm/helm-operator.md b/docs/helm-operator/tutorials/get-started.md
similarity index 55%
rename from docs/helm/helm-operator.md
rename to docs/helm-operator/tutorials/get-started.md
index 678357e6f..250a53e4e 100644
--- a/docs/helm/helm-operator.md
+++ b/docs/helm-operator/tutorials/get-started.md
@@ -1,38 +1,6 @@
-# Flux Helm Operator
-
-The Helm operator deals with Helm Chart releases. The operator watches for
-changes of Custom Resources of kind HelmRelease. It receives Kubernetes
-Events and acts accordingly, installing, upgrading or deleting a Chart release.
-
-## Setup and configuration
-
-helm-operator requires setup and offers customization though a multitude of flags.
-
-| flag | default | purpose
-| ------------------------ | ----------------------------- | ---
-| --kubeconfig | | Path to a kubeconfig. Only required if out-of-cluster.
-| --master | | The address of the Kubernetes API server. Overrides any value in kubeconfig. Only required if out-of-cluster.
-| --allow-namespace | | If set, this limits the scope to a single namespace. if not specified, all namespaces will be watched.
-| **Tiller options**
-| --tiller-ip | | Tiller IP address. Only required if out-of-cluster.
-| --tiller-port | | Tiller port.
-| --tiller-namespace | | Tiller namespace. If not provided, the default is kube-system.
-| --tiller-tls-enable | `false` | Enable TLS communication with Tiller. If provided, requires TLSKey and TLSCert to be provided as well.
-| --tiller-tls-verify | `false` | Verify TLS certificate from Tiller. Will enable TLS communication when provided.
-| --tiller-tls-key-path | `/etc/fluxd/helm/tls.key` | Path to private key file used to communicate with the Tiller server.
-| --tiller-tls-cert-path | `/etc/fluxd/helm/tls.crt` | Path to certificate file used to communicate with the Tiller server.
-| --tiller-tls-ca-cert-path | | Path to CA certificate file used to validate the Tiller server. Required if tiller-tls-verify is enabled.
-| --tiller-tls-hostname | | The server name used to verify the hostname on the returned certificates from the Tiller server.
-| **repo chart changes** (none of these need overriding, usually)
-| --charts-sync-interval | `3m` | Interval at which to check for changed charts.
-| --git-timeout | `20s` | Duration after which git operations time out.
-| --git-poll-interval | `5m` | Period on which to poll git chart sources for changes.
-| --log-release-diffs | `false` | Log the diff when a chart release diverges. **Potentially insecure.**
-| --update-chart-deps | `true` | Update chart dependencies before installing or upgrading a release.
-
-## Installing Flux Helm Operator and Helm with TLS enabled
-
-### Installing Helm / Tiller
+# Get started with the Helm operator
+
+## Installing Helm / Tiller
Generate certificates for Tiller and Flux. This will provide a CA, servercerts for Tiller and client certs for Helm / Flux.
@@ -171,7 +139,7 @@ helm --tls --tls-verify \
ls
```
-### Deploy Flux Helm Operator
+## Deploy the Helm Operator
First create a new Kubernetes TLS secret for the client certs;
@@ -202,30 +170,6 @@ helm upgrade --install \
> - include --tls flags for `helm` as in the `helm ls` example, if talking to a tiller with TLS
> - optionally specify target --namespace
-#### Check if it worked
+## Check if it worked
Use `kubectl logs` on the Helm Operator and observe the helm client being created.
-
-#### Debugging
-
-##### Error creating helm client: failed to append certificates from file: /etc/fluxd/helm-ca/ca.crt
-
-Your CA certificate content is not set correctly, check if your configMap contains the correct values. Example:
-
-```bash
-$ kubectl get configmaps flux-helm-tls-ca-config -o yaml
-apiVersion: v1
-data:
- ca.crt: |
- -----BEGIN CERTIFICATE-----
- ....
- -----END CERTIFICATE-----
-kind: ConfigMap
-metadata:
- creationTimestamp: 2018-07-04T15:27:25Z
- name: flux-helm-tls-ca-config
- namespace: helm-system
- resourceVersion: "1267257"
- selfLink: /api/v1/namespaces/helm-system/configmaps/flux-helm-tls-ca-config
- uid: c106f866-7f9e-11e8-904a-025000000001
-```
diff --git a/docs/helm-operator/tutorials/index.rst b/docs/helm-operator/tutorials/index.rst
new file mode 100644
index 000000000..a37796c8e
--- /dev/null
+++ b/docs/helm-operator/tutorials/index.rst
@@ -0,0 +1,10 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Tutorials
+=========
+
+.. toctree::
+ :maxdepth: 1
+
+ get-started
diff --git a/docs/helm/index.rst b/docs/helm/index.rst
deleted file mode 100644
index ae257ba69..000000000
--- a/docs/helm/index.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-.. Flux documentation documentation master file, created by
- sphinx-quickstart on Wed Jun 12 16:13:18 2019.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Using Flux with Helm
-==============================================
-
-.. toctree::
- :maxdepth: 2
- :caption: Contents:
-
- helm-integration
- helm-operator
diff --git a/docs/index.rst b/docs/index.rst
index 59eb74b45..f4811696b 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,27 +1,32 @@
-.. Flux documentation documentation master file, created by
- sphinx-quickstart on Wed Jun 12 16:13:18 2019.
- You can adapt this file completely to your liking, but it should at least
+.. You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Welcome to Flux's documentation!
-==============================================
+================================
.. toctree::
- :maxdepth: 1
- :caption: Contents:
-
+ :maxdepth: 2
+ :caption: Flux
introduction
requirements
+ get-started/index
- install/index
- using/index
- helm/index
-
- how-it-works
-
- features/index
- development/index
+ references/index
+ guides/index
+ tutorials/index
faq
troubleshooting
+
+.. toctree::
+ :maxdepth: 3
+ :caption: Helm operator
+
+ helm-operator/index
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contributing
+
+ contributing/index
diff --git a/docs/install/index.md b/docs/install/index.md
deleted file mode 100644
index df006e80f..000000000
--- a/docs/install/index.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Installing Flux
-
-All you need is a Kubernetes cluster and a git repo. The git repo
-contains [manifests][k8s-manifests] (as YAML files) describing what
-should run in the cluster. Flux imposes
-[some requirements](../requirements.md) on these files.
-
-Here are the instructions to [install Flux on your own
-cluster](./get-started.md).
-
-If you are using Helm, we have a [separate section about
-this](./helm-get-started.md).
-
-You can also configure a more advanced, [standalone
-setup](./standalone-setup.md).
-
-[k8s-manifests]: https://kubernetes.io/docs/concepts/configuration/overview/
diff --git a/docs/install/standalone-setup.md b/docs/install/standalone-setup.md
deleted file mode 100644
index cb323d028..000000000
--- a/docs/install/standalone-setup.md
+++ /dev/null
@@ -1,187 +0,0 @@
-# Customising the deployment
-
-## Customising the daemon configuration
-
-The deployment installs Flux and its dependencies. First, change to
-the directory with the examples configuration.
-
-### Connect Flux to a repository
-
-First, you need to connect Flux to the repository with Kubernetes
-manifests. This is achieved by setting the `--git-url` and
-`--git-branch` arguments in the
-[`flux-deployment.yaml`](https://github.com/weaveworks/flux/blob/master/deploy/flux-deployment.yaml) manifest.
-
-### Flux deployment
-
-You will need to create a secret in which Flux will store its SSH
-key. The daemon won't start without this present.
-
-The `flux` logs should show that it has now connected to the
-repository and synchronised the cluster.
-
-When using Kubernetes, this key is stored as a Kubernetes secret. You
-can restart `flux` and it will continue to use the same key.
-
-### Add an SSH deploy key to the repository
-
-Flux connects to the repository using an SSH key.
-
-***The SSH key must be configured to have R/W access to the repository***.
-
-More specifically, in the case of standalone Flux, the ssh key must be able to
-create and update tags. E.g. in Gitlab, that means it requires `Maintainer`
-permissions. The `Developer` permission can create tags, but not update them.
-
-You have two options:
-
-#### 1. Allow Flux to generate a key for you.
-
-If you don't specify a key to use, Flux will create one for you. Obtain
-the public key through [fluxctl](../using/fluxctl.md):
-
-```sh
-fluxctl identity
-```
-
-#### 2. Specify a key to use
-
-Create a Kubernetes Secret from a private key:
-
-```sh
-kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/private_key
-```
-
-this will result in a secret that has the structure:
-
-```yaml
- apiVersion: v1
- data:
- identity: <base64 encoded RSA PRIVATE KEY>
- kind: Secret
- type: Opaque
- metadata:
- ...
-```
-
-The Kubernetes deployment configuration file
-[flux-deployment.yaml](https://github.com/weaveworks/flux/blob/master/deploy/flux-deployment.yaml) runs the
-Flux daemon, but you'll need to edit it first, at least to supply your
-own configuration repo (the `--git-repo` argument).
-
-```sh
-$EDITOR flux-deployment.yaml
-kubectl create -f flux-deployment.yaml
-```
-
-#### Note for Kubernetes >=1.6 with role-based access control (RBAC)
-
-You will need to provide fluxd with a service account which can access
-the namespaces you want to use Flux with. To do this, consult the
-example service account given in
-[flux-account.yaml](https://github.com/weaveworks/flux/blob/master/deploy/flux-account.yaml) (which
-puts essentially no constraints on the account) and the
-[RBAC documentation](https://kubernetes.io/docs/admin/authorization/rbac/),
-and create a service account in whichever namespace you put fluxd
-in. You may need to alter the `namespace: default` lines, if you adapt
-the example.
-
-Using an SSH key allows you to maintain control of the repository. You
-can revoke permission for `flux` to access the repository at any time
-by removing the deploy key.
-
-### Using a private git host
-
-If you're using your own git host -- e.g., your own installation of
-gitlab, or bitbucket server -- you will need to add its host key to
-`~/.ssh/known_hosts` in the Flux daemon container.
-
-First, run a check that you can clone the repo. The following assumes
-that your git server's hostname (e.g., `githost`) is in `$GITHOST` and
-the URL you'll use to access the repository (e.g.,
-`user@githost:path/to/repo`) is in `$GITREPO`.
-
-```sh
-$ # Find the fluxd daemon pod:
-$ kubectl get pods --all-namespaces -l name=flux
-NAMESPACE NAME READY STATUS RESTARTS AGE
-weave flux-85cdc6cdfc-n2tgf 1/1 Running 0 1h
-
-$ kubectl exec -n weave flux-85cdc6cdfc-n2tgf -ti -- \
- env GITHOST="$GITHOST" GITREPO="$GITREPO" PS1="container$ " /bin/sh
-
-container$ git clone $GITREPO
-Cloning into <repository name>...
-No ECDSA host key is known for <GITHOST> and you have requested strict checking.
-Host key verification failed.
-fatal: Could not read from remote repository
-
-container$ # ^ that was expected. Now we'll try with a modified known_hosts
-container$ ssh-keyscan $GITHOST >> ~/.ssh/known_hosts
-container$ git clone $GITREPO
-Cloning into '...'
-...
-```
-
-If `git clone` doesn't succeed, you'll need to check that the SSH key
-has been installed properly first, then come back. `ssh -vv $GITHOST`
-from within the container may help debug it.
-
-If it _did_ work, you will need to make it a more permanent
-arrangement. Back in that shell, create a configmap for the cluster. To make
-sure the configmap is created in the namespace of the Flux or weave deployment,
-the namespace is set explicitly:
-
-```sh
-container$ kubectl create configmap flux-ssh-config --from-file=$HOME/.ssh/known_hosts -n $(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
-configmap "flux-ssh-config" created
-```
-
-To use the ConfigMap every time the Flux daemon restarts, you'll need
-to mount it into the container. The example deployment manifest
-includes an example of doing this, commented out. Uncomment those two blocks:
-
-```yaml
- - name: ssh-config
- configMap:
- name: flux-ssh-config
-```
-
-```yaml
- - name: ssh-config
- mountPath: /root/.ssh
-```
-
-It assumes you used `flux-ssh-config` as name of the ConfigMap and then reapply the
-manifest.
-
-Another alternative is to create the configmap from a template. This could be
-something like:
-
-```yaml
-apiVersion: v1
-data:
- known_hosts: |
- # github
- 192.30.253.112 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
- # github
- 192.30.253.113 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
- # private gitlab
- gitlab.________ ssh-rsa AAAAB3N...
-kind: ConfigMap
-metadata:
- name: flux-ssh-config
- namespace: <OPTIONAL NAMESPACE (if not default)>
-```
-
-You will need to explicitly tell fluxd to use that service account by
-uncommenting and possible adapting the line `# serviceAccountName:
-flux` in the file `fluxd-deployment.yaml` before applying it.
-
-### Memcache
-
-Flux uses memcache to cache docker registry requests.
-
-```sh
-kubectl create -f memcache-dep.yaml -f memcache-svc.yaml
-```
diff --git a/docs/how-it-works.md b/docs/references/blueprint.md
similarity index 87%
rename from docs/how-it-works.md
rename to docs/references/blueprint.md
index b3a768b64..8c83a73fe 100644
--- a/docs/how-it-works.md
+++ b/docs/references/blueprint.md
@@ -1,10 +1,10 @@
-# How Flux Works
+# Blueprint
-This page describes the goals of flux, how it achieves them and
+This page describes the goals of Flux, how it achieves them and
significant architectural decisions. It is intentionally high level
to prevent it from being out of date too quickly.
-## Goals
+## Flux's goals
The overall goal of Flux is to automate the deployment of services.
A typical use case would be:
@@ -20,11 +20,10 @@ with an orchestrator (which is a common source of accidental failure) or
with the systems that ensure that the orchestrator is in a working
state.
-Flux provides a CLI ([`fluxctl`](./using/fluxctl.md)) and a UI (as a component of Weave Cloud)
-to perform these operations manually. Flux is flexible enough to fit
-into any development process.
+Flux provides a CLI ([`fluxctl`](fluxctl.md)) to perform these operations
+manually. Flux is flexible enough to fit into any development process.
-## Implementation Overview
+## Implementation overview
The following describes how Flux achieves the goals.
@@ -48,7 +47,7 @@ cluster to match the code representing the cluster in the repository.
This simple idea then allows for a whole range of tools that can react
to changes and simply write to a repository.
-### Monitoring For New Images
+### Monitoring for new images
Flux reads a list of running containers from the user git repository.
For each image, it will query the container registry to obtain the most
@@ -65,7 +64,7 @@ When automation is disabled, images are not checked.
In order to access private registries, credentials may be required.
-### Deployment of Images
+### Deployment of images
Flux will only deploy different images. It will not re-deploy images
with the same tag.
diff --git a/docs/features/daemon.md b/docs/references/daemon.md
similarity index 83%
rename from docs/features/daemon.md
rename to docs/references/daemon.md
index 1da66c8cd..6759eae00 100644
--- a/docs/features/daemon.md
+++ b/docs/references/daemon.md
@@ -1,45 +1,39 @@
-# Flux Daemon
+# Daemon (`fluxd`)
## Summary
-Flux daemon (fluxd, aka Flux agent) allows automation of application deployments and version control of cluster configuration.
+Flux daemon (`fluxd`, aka Flux agent) allows automation of application deployments and version control of cluster configuration.
Version controlling of cluster manifests provides reproducibility and a historical trail of events.
-### Flux daemon responsibilities
+### Responsibilities
- A) Continuous Deployment
- 1.
- Flux daemon monitors user git repo Kubernetes manifests for changes, which it
- then deploys to the cluster.
+#### Continuous Deployment
- 2.
- Flux daemon monitors container registry for running container image updates.
- Detection of an image change (running container image tag vs container
- registry image tag) triggers k8s manifest update, which is committed to the
- user git repository, then deployed to the Kubernetes cluster.
+1. Flux daemon monitors user git repo Kubernetes manifests for
+ changes, which it then deploys to the cluster.
- B) Deployment approaches
- 1.
- Automate vs Deautomate
- Deployment happens automatically when a new image tag is detected.
- Deautomated deployment will not proceed until manually released (through
- the UI or the CLI tool fluxctl).
+2. Flux daemon monitors container registry for running container image
+ updates. Detection of an image change (running container image tag
+ vs container registry image tag) triggers k8s manifest update, which
+ is committed to the user git repository, then deployed to the
+ Kubernetes cluster.
- 2.
- Lock vs Unlock
- Deployment is pinned to a particular image tag. New deployment will not
- proceed upon triggered release.
+#### Deployment approaches
+
+1. Automate vs Deautomate
-## More information
+ Deployment happens automatically when a new image tag is
+ detected. Deautomated deployment will not proceed until
+ manually released (through the CLI tool `fluxctl`).
-Setting up and configuring fluxd is discussed in our [standalone setup](../install/standalone-setup.md)
-document.
+2. Lock vs Unlock
-There is also more information on [garbage collection](./garbagecollection.md) and [Git commit signing](../using/git-gpg.md).
+ Deployment is pinned to a particular image tag.
+ New deployment will not proceed upon triggered release.
-## Flags
+## Setup and configuration
-fluxd requires setup and offers customization though a multitude of flags.
+`fluxd` requires setup and offers customization though a multitude of flags.
| Flag | Default | Purpose
| ------------------------------------------------ | ---------------------------------- | ---
@@ -48,7 +42,7 @@ fluxd requires setup and offers customization though a multitude of flags.
| --kubernetes-kubectl | | optional, explicit path to kubectl tool
| --version | false | output the version number and exit
| **Git repo & key etc.**
-| --git-url | | URL of git repo with Kubernetes manifests; e.g., `git@github.com:weaveworks/flux-get-started`
+| --git-url | | URL of git repo with Kubernetes manifests; e.g., `git@github.com:fluxcd/flux-get-started`
| --git-branch | `master` | branch of git repo to use for Kubernetes manifests
| --git-ci-skip | false | when set, fluxd will append `\n\n[ci skip]` to its commit messages
| --git-ci-skip-message | `""` | if provided, fluxd will append this to commit messages (overrides --git-ci-skip`)
@@ -95,3 +89,11 @@ fluxd requires setup and offers customization though a multitude of flags.
| --ssh-keygen-type | | -t argument to ssh-keygen (default unspecified)
| **manifest generation**
| --manifest-generation | false | experimental; search for .flux.yaml files to generate manifests
+
+## More information
+
+Setting up and configuring `fluxd` is discussed in
+["Get started with Flux"](../tutorials/get-started.md).
+
+There is also more information on [garbage collection](garbagecollection.md),
+[Git commit signing](git-gpg.md), and other elements in [references](./).
diff --git a/docs/using/fluxctl.md b/docs/references/fluxctl.md
similarity index 99%
rename from docs/using/fluxctl.md
rename to docs/references/fluxctl.md
index a85fc9dd7..fd79aa2c6 100644
--- a/docs/using/fluxctl.md
+++ b/docs/references/fluxctl.md
@@ -1,10 +1,10 @@
-# Using Flux
+# `fluxctl`
`fluxctl` provides an API that can be used from the command line.
The `--help` for `fluxctl` is described below.
-## Installing fluxctl
+## Installing `fluxctl`
### Mac OS
@@ -51,9 +51,9 @@ makepkg -si
With every release of Flux, we release binaries of `fluxctl` for Mac, Linux
and Windows. Download them from the [Flux release
-page](https://github.com/weaveworks/flux/releases).
+page](https://github.com/fluxcd/flux/releases).
-## Connecting fluxctl to the daemon
+## Connecting `fluxctl` to the daemon
By default, `fluxctl` will attempt to port-forward to your Flux
instance, assuming it runs in the `"default"` namespace. You can
@@ -418,7 +418,7 @@ started with several flags that impact the commit information:
Actions triggered by a user through the CLI `fluxctl`
tool, can have the commit author information customized. This is handy for providing extra context in the
-notifications and history. Whether the customization is possible, depends on the Flux daemon (fluxd)
+notifications and history. Whether the customization is possible, depends on the Flux daemon (`fluxd`)
`git-set-author` flag. If set, the commit author will be customized in the following way:
## Image Tag Filtering
@@ -598,14 +598,14 @@ no existing author
## Using Annotations
Automation and image tag filtering can also be managed using annotations
-(fluxctl is using the same mechanism).
+(`fluxctl` is using the same mechanism).
Automation can be enabled with `flux.weave.works/automated: "true"`. Image
filtering annotations take the form
`flux.weave.works/tag.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.
+configured using `fluxctl`.
Here's a simple but complete deployment file with annotations:
diff --git a/docs/features/fluxyaml-config-files.md b/docs/references/fluxyaml-config-files.md
similarity index 97%
rename from docs/features/fluxyaml-config-files.md
rename to docs/references/fluxyaml-config-files.md
index 492f9cfad..775511876 100644
--- a/docs/features/fluxyaml-config-files.md
+++ b/docs/references/fluxyaml-config-files.md
@@ -26,7 +26,7 @@ Flux performs two types of actions on raw manifest files from the Git repository
1. Read manifest files when performing a sync operation (i.e making sure that the status of the cluster reflects what's
in the manifest files, adjusting it if necessary)
-2. Update the manifest files of [workload](https://github.com/weaveworks/flux/blob/master/docs/using/fluxctl.md#what-is-a-workload).
+2. Update the manifest files of [workload](https://github.com/fluxcd/flux/blob/master/docs/using/fluxctl.md#what-is-a-workload).
Specifically, flux can update:
* container images, when releasing a new image version. A release can happen manually or automatically, when a new
container image is pushed to a repository.
@@ -82,7 +82,7 @@ command and a `policy` command, covering the corresponding two types of workload
> * Some configurations (even those for Kubernetes clusters) may encode policies symbolically.
Here is a specific `.flux.yaml` example, declaring a generator and an updater using [Kustomize](https://github.com/kubernetes-sigs/kustomize)
-(see [https://github.com/weaveworks/flux-kustomize-example](https://github.com/weaveworks/flux-kustomize-example)
+(see [https://github.com/fluxcd/flux-kustomize-example](https://github.com/fluxcd/flux-kustomize-example)
for a complete example).
```yaml
@@ -130,7 +130,7 @@ a separate configuration file variant (`patchedUpdated`) is provided, which will
### Execution context of commands
`generators` and `updaters` are run in a POSIX shell inside the Flux container. This means that the `command`s supplied
-should be available in the [Flux container image](https://github.com/weaveworks/flux/blob/master/docker/Dockerfile.flux).
+should be available in the [Flux container image](https://github.com/fluxcd/flux/blob/master/docker/Dockerfile.flux).
Flux currently includes `Kustomize` and basic Unix shell tools. If the tools in the Flux image are not sufficient for
your use case, you can include new tools in your own Flux-based image or, if the tools are popular enough, Flux
maintainers can add them to the Flux image (please create an issue). In the future (once [Ephemeral
diff --git a/docs/features/garbagecollection.md b/docs/references/garbagecollection.md
similarity index 84%
rename from docs/features/garbagecollection.md
rename to docs/references/garbagecollection.md
index eecd83c68..525e4549d 100644
--- a/docs/features/garbagecollection.md
+++ b/docs/references/garbagecollection.md
@@ -2,7 +2,7 @@
Part of syncing a cluster with a git repository is getting rid of
resources in the cluster that have been removed in the repository. You
-can tell fluxd to do this "garbage collection" using the command-line
+can tell `fluxd` to do this "garbage collection" using the command-line
flag `--sync-garbage-collection`. It's important to know how it
operates, and appreciate its limitations, before enabling it.
@@ -18,18 +18,18 @@ When garbage collection is enabled, syncing is done in two phases:
source, and delete those that were not applied in step 1.
In the above, "source" refers to the particular combination of git
-repo URL, branch, and paths that this fluxd has been configured to
-use, which is taken as identifying the resources under _this_ fluxd's
-control.
+repo URL, branch, and paths that this `fluxd` has been configured to
+use, which is taken as identifying the resources under _this_
+`fluxd`'s control.
We need to be careful about identifying these accurately, since
getting it wrong could mean _not_ deleting resources that should be
deleted; or (much worse), deleting resources that are under another
-fluxd's control.
+`fluxd`'s control.
The definition of "source" affects how garbage collection behaves when
-you reconfigure fluxd. It is intended to be conservative: it ensures
-that fluxd will not delete resources that it did not create.
+you reconfigure `fluxd`. It is intended to be conservative: it ensures
+that `fluxd` will not delete resources that it did not create.
## Limitations of this approach
diff --git a/docs/using/git-gpg.md b/docs/references/git-gpg.md
similarity index 100%
rename from docs/using/git-gpg.md
rename to docs/references/git-gpg.md
diff --git a/docs/references/helm-operator-integration.md b/docs/references/helm-operator-integration.md
new file mode 100644
index 000000000..3fec6df1f
--- /dev/null
+++ b/docs/references/helm-operator-integration.md
@@ -0,0 +1,123 @@
+# Integration with the Helm operator
+
+You can release charts to your cluster via "GitOps", by combining Flux
+and the Helm operator (also in [fluxcd/flux](https://github.com/fluxcd/flux)).
+
+The essential mechanism is this: the declaration of a Helm release is
+represented by a custom resource, specifying the chart and its
+values. If you put such a resource in your git repo as a file, Flux
+will apply it to the cluster, and once it's in the cluster, the Helm
+Operator will make sure the release exists by installing or upgrading
+it.
+
+## Upgrading images in a `HelmRelease` using Flux
+
+If the chart you're using in a `HelmRelease` lets you specify the
+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`.
+
+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):
+
+```yaml
+values:
+ image: repo/image:version
+```
+
+```yaml
+values:
+ image: repo/image
+ tag: version
+```
+
+```yaml
+values:
+ registry: docker.io
+ image: repo/image
+ tag: version
+```
+
+```yaml
+values:
+ image:
+ repository: repo/image
+ tag: version
+```
+
+```yaml
+values:
+ image:
+ registry: docker.io
+ repository: repo/image
+ tag: version
+```
+
+These can appear at the top level (immediately under `values:`), or in
+a subsection (under a key, itself under `values:`). Other values
+may be mixed in arbitrarily. Here's an example of a values section
+that specifies two images, along with some other configuration:
+
+```yaml
+values:
+ persistent: true
+
+ # image that will be labeled "chart-image"
+ image: repo/image1:version
+
+ subsystem:
+ # image that will be labeled "subsystem"
+ image:
+ repository: repo/image2
+ tag: version
+ imagePullPolicy: IfNotPresent
+ port: 4040
+```
+
+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).
+
+Top level image example:
+
+```yaml
+kind: HelmRelease
+metadata:
+ annotations:
+ flux.weave.works/automated: "true"
+ flux.weave.works/tag.chart-image: semver:~4.0
+spec:
+ values:
+ image:
+ repository: bitnami/mongodb
+ tag: 4.0.3
+```
+
+Sub-section images example:
+
+```yaml
+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.*
+spec:
+ values:
+ prometheus:
+ image: prom/prometheus:v2.3.1
+ alertmanager:
+ image: prom/alertmanager:v0.15.0
+ nats:
+ image:
+ repository: nats-streaming
+ tag: 0.6.0
+```
diff --git a/docs/references/index.rst b/docs/references/index.rst
new file mode 100644
index 000000000..e68a1dcfb
--- /dev/null
+++ b/docs/references/index.rst
@@ -0,0 +1,17 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+References
+==========
+
+.. toctree::
+ :maxdepth: 1
+
+ blueprint
+ daemon
+ fluxctl
+ fluxyaml-config-files
+ garbagecollection
+ git-gpg
+ helm-operator-integration
+ monitoring
diff --git a/docs/using/monitoring.md b/docs/references/monitoring.md
similarity index 100%
rename from docs/using/monitoring.md
rename to docs/references/monitoring.md
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index 4e05a7870..d3c70cc7d 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -1,22 +1,22 @@
-# Troubleshooting Weave Flux
+# Troubleshooting
Also see the [issues labeled with
-`FAQ`](https://github.com/weaveworks/flux/labels/FAQ), which often
+`FAQ`](https://github.com/fluxcd/flux/labels/FAQ), which often
explain workarounds.
-### Flux is taking a long time to apply manifests when it syncs
+## Flux is taking a long time to apply manifests when it syncs
If you notice that Flux takes tens of seconds or minutes to get
through each sync, while you can apply the same manifests very quickly
by hand, you may be running into this issue:
-https://github.com/weaveworks/flux/issues/1422
+https://github.com/fluxcd/flux/issues/1422
Briefly, the problem is that mounting a volume into `$HOME/.kube`
effectively disables `kubectl`'s caching, which makes it much much
slower. You may have used such a volume mount to override
`$HOME/.kube/config`, possibly unknowingly -- the Helm chart did this
for you, prior to
-[weaveworks/flux#1435](https://github.com/weaveworks/flux/pull/1435).
+[fluxcd/flux#1435](https://github.com/fluxcd/flux/pull/1435).
The remedy is to mount the override to some other place in the
filesystem, and use the environment entry `KUBECONFIG` to point
@@ -26,11 +26,11 @@ may be as easy as reapplying the chart if that's what you're using.
This is also documented in the
[FAQ](./faq.md).
-### `fluxctl` returns a 500 Internal Server Error
+## `fluxctl` returns a 500 Internal Server Error
-This usually indicates there's a bug in the Flux daemon somewhere -- in which case please [tell us about it](https://github.com/weaveworks/flux/issues/new)!
+This usually indicates there's a bug in the Flux daemon somewhere -- in which case please [tell us about it](https://github.com/fluxcd/flux/issues/new)!
-### Flux answers everything with `git repo is not configured`
+## Flux answers everything with `git repo is not configured`
This means Flux can't read from and write to the git repo. Check that
@@ -46,19 +46,19 @@ This means Flux can't read from and write to the git repo. Check that
- ... that the host where your git repo lives is in
`~/.ssh/known_hosts` in the fluxd container. We prime the container
_image_ with host keys for `github.com`, `gitlab.com`, `bitbucket.org`, `dev.azure.com`, and `vs-ssh.visualstudio.com`, but if you're using your own git server, you'll
- need to add its host key. See [./standalone-setup.md](./install/standalone-setup.md).
+ need to add its host key. See ["Using a private Git host"](./guides/use-private-git-host.md).
-### I'm using GCR/GKE and I keep seeing "Quota exceeded" in logs
+## I'm using GCR/GKE and I keep seeing "Quota exceeded" in logs
GCP (in general) has quite conservative API rate limiting, and Flux's
default settings can bump API usage over the limits. See
-[weaveworks/flux#1016](https://github.com/weaveworks/flux/issues/1016)
+[fluxcd/flux#1016](https://github.com/fluxcd/flux/issues/1016)
for advice.
-### Flux doesn't seem to be able to use my imagePullSecrets
+## Flux doesn't seem to be able to use my imagePullSecrets
If you're using `kubectl` v1.13.x to create them, then it may be due
-to [this problem](https://github.com/weaveworks/flux/issues/1596). In
+to [this problem](https://github.com/fluxcd/flux/issues/1596). In
short, there was a breaking change to how `kubectl` creates secrets,
that found its way into the Kubernetes 1.13.0 release. It has been
corrected in [kubectl
@@ -66,7 +66,7 @@ v1.13.2](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#
so using that version or newer to create secrets should fix the
problem.
-### Why are my images not showing up in the list of images?
+## Why are my images not showing up in the list of images?
Sometimes, instead of seeing the various images and their tags, the
output of `fluxctl list-images` shows nothing. There's a number of
@@ -77,10 +77,10 @@ reasons this can happen:
- Flux can't get suitable credentials for the image repository. At
present, it looks at `imagePullSecret`s attached to workloads,
service accounts, platform-provided credentials on GCP, AWS or Azure, and
- a Docker config file if you mount one into the fluxd container (see
- the [command-line usage](./features/daemon.md)).
+ a Docker config file if you mount one into the `fluxd` container (see
+ the [command-line usage](references/daemon.md)).
- When using images in ECR, from EC2, the `NodeInstanceRole` for the
- worker node running fluxd must have permissions to query the ECR
+ worker node running `fluxd` must have permissions to query the ECR
registry (or registries) in
question. [`eksctl`](https://github.com/weaveworks/eksctl) and
[`kops`](https://github.com/kubernetes/kops) (with
@@ -88,8 +88,8 @@ reasons this can happen:
both make sure this is the case.
- When using images from ACR in AKS, the HostPath `/etc/kubernetes/azure.json`
should be [mounted](https://kubernetes.io/docs/concepts/storage/volumes/) into the Flux Pod.
- Set `registry.acr.enabled=True` in the [helm chart](https://github.com/weaveworks/flux/blob/master/chart/flux/README.md)
- or alter the [Deployment](https://github.com/weaveworks/flux/blob/master/deploy/flux-deployment.yaml):
+ Set `registry.acr.enabled=True` in the [helm chart](https://github.com/fluxcd/flux/blob/master/chart/flux/README.md)
+ or alter the [Deployment](https://github.com/fluxcd/flux/blob/master/deploy/flux-deployment.yaml):
```yaml
spec:
containers:
@@ -108,12 +108,12 @@ reasons this can happen:
- Flux excludes images with no suitable manifest (linux amd64) in manifestlist
- Flux doesn't yet understand image refs that use digests instead of
tags; see
- [weaveworks/flux#885](https://github.com/weaveworks/flux/issues/885).
+ [fluxcd/flux#885](https://github.com/fluxcd/flux/issues/885).
If none of these explanations seem to apply, please
-[file an issue](https://github.com/weaveworks/flux/issues/new).
+[file an issue](https://github.com/fluxcd/flux/issues/new).
-### Why do my image tags appear out of order?
+## Why do my image tags appear out of order?
You may notice that the ordering given to image tags does not always
correspond with the order in which you pushed the images. That's
@@ -133,7 +133,7 @@ build has its own creation time is to label it with a build time;
e.g., using
[OpenContainers pre-defined annotations](https://github.com/opencontainers/image-spec/blob/master/annotations.md).
-### What is the "sync tag"; or, why do I see a `flux-sync` tag in my git repo?
+## What is the "sync tag"; or, why do I see a `flux-sync` tag in my git repo?
Flux keeps track of the last commit that it's applied to the cluster,
by pushing a tag (controlled by the command-line flags
diff --git a/docs/using/annotations-tutorial.md b/docs/tutorials/driving-flux.md
similarity index 95%
rename from docs/using/annotations-tutorial.md
rename to docs/tutorials/driving-flux.md
index a86da9d18..a9a4c0d91 100644
--- a/docs/using/annotations-tutorial.md
+++ b/docs/tutorials/driving-flux.md
@@ -1,4 +1,4 @@
-# Driving Flux - automations, locks and annotations
+# Automations, locks and annotations
In this tutorial we want to get a better feel for what we can do with
Flux. We won't spend too much time with getting it up and running, so let's
@@ -6,7 +6,7 @@ get that out of the way first.
In our example we are going to use the `flux-get-started` example deployment.
So as your first step, please head to [our example
-deployment](https://github.com/weaveworks/flux-get-started) and click on the
+deployment](https://github.com/fluxcd/flux-get-started) and click on the
"Fork" button.
## Setup
@@ -14,7 +14,7 @@ deployment](https://github.com/weaveworks/flux-get-started) and click on the
Get the source code of Flux:
```sh
-git clone https://github.com/weaveworks/flux
+git clone https://github.com/fluxcd/flux
cd flux
```
@@ -27,7 +27,7 @@ EDITOR deploy/flux-deployment.yaml
And update the following line
```yaml
- --git-url=git@github.com:weaveworks/flux-get-started
+ --git-url=git@github.com:fluxcd/flux-get-started
```
to point to your fork, e.g. if your GitHub Login is `baloothebear`, the line
@@ -98,7 +98,7 @@ fluxcd/flux
> **Note:** In this tutorial we keep things simple, so we deploy Flux into
the `default` namespace. Normally you would pick a separate namespace for
-it. `fluxctl` has the [`--k8s-fwd-ns <NAMESPACE>` option](./fluxctl.md) for specifying the right
+it. `fluxctl` has the [`--k8s-fwd-ns <NAMESPACE>` option](../references/fluxctl.md) for specifying the right
namespace.
### Connecting to your git config
@@ -107,7 +107,7 @@ 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](./fluxctl.md).
+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
`fluxctl -h` to get a better idea.)
diff --git a/docs/install/helm-get-started.md b/docs/tutorials/get-started-helm.md
similarity index 87%
rename from docs/install/helm-get-started.md
rename to docs/tutorials/get-started-helm.md
index 95c028b0a..2e67a944f 100644
--- a/docs/install/helm-get-started.md
+++ b/docs/tutorials/get-started-helm.md
@@ -1,6 +1,4 @@
-# Installing Flux using Helm
-
-## Get started with Flux using Helm
+# Get started with Flux using Helm
If you are using Helm already, this guide is for you. By the end
you will have Helm installing Flux in the cluster and deploying
@@ -8,9 +6,9 @@ any code changes for you.
If you are looking for more generic notes for how to install Flux
using Helm, we collected them [in the chart's
-README](https://github.com/weaveworks/flux/blob/master/chart/flux/README.md).
+README](https://github.com/fluxcd/flux/blob/master/chart/flux/README.md).
-### Prerequisites
+## Prerequisites
You will need to have Kubernetes set up. To get up and running fast,
you might want to use `minikube` or `kubeadm`. Any other Kubernetes
@@ -49,7 +47,7 @@ helm init --skip-refresh --upgrade --service-account tiller --history-max 10
> and be aware of the `--history-max` flag before promoting to
> production.
-### Install Flux
+## Install Flux
Add the Flux repository:
@@ -65,10 +63,10 @@ kubectl apply -f https://raw.githubusercontent.com/fluxcd/flux/master/deploy-hel
In this next step you install Flux using `helm`. Simply
- 1. Fork [flux-get-started](https://github.com/weaveworks/flux-get-started)
- on GitHub and replace the `weaveworks` with your GitHub username in
- [here](https://github.com/weaveworks/flux-get-started/blob/master/releases/ghost.yaml#L13)
- 1. Install Flux and its Helm Operator by specifying your fork URL:
+ 1. Fork [`fluxcd/flux-get-started`](https://github.com/fluxcd/flux-get-started)
+ on GitHub and replace the `fluxcd` with your GitHub username in
+ [here](https://github.com/fluxcd/flux-get-started/blob/master/releases/ghost.yaml#L13)
+ 1. Install Flux and the Helm operator by specifying your fork URL:
*Just make sure you replace `YOURUSER` with your GitHub username
in the command below:*
@@ -88,7 +86,7 @@ In this next step you install Flux using `helm`. Simply
When deploying from a private repo, the known_hosts of the git server needs
to be configured into a kubernetes configmap so that `StrictHostKeyChecking` is respected.
- See [chart/flux/README.md](https://github.com/weaveworks/flux/blob/master/chart/flux/README.md#to-install-flux-with-the-helm-operator-and-a-private-git-repository)
+ See the [README of the chart](https://fluxcd/flux/blob/master/chart/flux/README.md#to-install-flux-with-the-helm-operator-and-a-private-git-repository)
for further installation instructions in this case.
Allow some time for all containers to get up and running. If you're
@@ -102,7 +100,7 @@ watch kubectl -n flux get pods
You will notice that `flux` and `flux-helm-operator` will start
turning up in the `flux` namespace.
-### Giving write access
+## Giving write access
For the real benefits of GitOps, Flux will need access to your
git repository to update configuration if necessary. To facilitate
@@ -111,7 +109,7 @@ repository.
This is pretty straight-forward as Flux generates a SSH key and
logs the public key at startup. Find the SSH public key by
-installing [fluxctl](../using/fluxctl.md) and running:
+installing [`fluxctl`](../references/fluxctl.md) and running:
```sh
fluxctl identity --k8s-fwd-ns flux
@@ -138,7 +136,7 @@ deployed into the `demo` namespace) listed like so:
helm list --namespace demo
```
-### Committing a small change
+## Committing a small change
`flux-get-started` is a simple example in which three services
(mongodb, redis and ghost) are deployed. Here we will simply update the
@@ -179,7 +177,7 @@ Flux is deploying to:
kubectl describe -n demo deployment/mongodb | grep Image
```
-### Conclusion
+## Conclusion
As you can see, the actual steps to set up Flux, get our app
deployed, give Flux access to it and see modifications land are
diff --git a/docs/install/get-started.md b/docs/tutorials/get-started.md
similarity index 62%
rename from docs/install/get-started.md
rename to docs/tutorials/get-started.md
index 4de5f9a26..60a448258 100644
--- a/docs/install/get-started.md
+++ b/docs/tutorials/get-started.md
@@ -1,6 +1,4 @@
-# Installing Flux Manually
-
-## Get started with Flux
+# Get started with Flux
This short guide shows a self-contained example of Flux and just
takes a couple of minutes to get set up. By the end you will
@@ -8,36 +6,36 @@ have Flux running in your cluster and it will be deploying any
code changes for you.
> **Note:** If you would like to install Flux using Helm, refer to the
-> [Helm section](./helm-get-started.md).
+> [Helm section](get-started-helm.md).
-### Prerequisites
+## Prerequisites
You will need to have Kubernetes set up. For a quick local test,
you can use `minikube` or `kubeadm`. Any other Kubernetes setup
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:
->
-> ```sh
-> kubectl create clusterrolebinding "cluster-admin-$(whoami)" --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
-> ```
->
-> to avoid an error along the lines of
->
-> ```sh
-> Error from server (Forbidden): error when creating "deploy/flux-account.yaml":
-> clusterroles.rbac.authorization.k8s.io "flux" is forbidden: attempt to grant
-> extra privileges:
-> ```
-
-### Set up Flux
+### A note on GKE with RBAC enabled
+
+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)"
+```
+
+to avoid an error along the lines of:
+
+```sh
+Error from server (Forbidden): error when creating "deploy/flux-account.yaml":
+clusterroles.rbac.authorization.k8s.io "flux" is forbidden: attempt to grant
+extra privileges:
+```
+
+## Set up Flux
Get Flux:
```sh
-git clone https://github.com/weaveworks/flux
+git clone https://github.com/fluxcd/flux
cd flux
```
@@ -50,15 +48,15 @@ you. You are going to need access to this repository.
$EDITOR deploy/flux-deployment.yaml
```
-In our example we are going to use
-[flux-get-started](https://github.com/weaveworks/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
-[Helm section](./helm-get-started.md).
+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
+## Deploying Flux to the cluster
In the next step, deploy Flux to the cluster:
@@ -74,11 +72,11 @@ process.
watch kubectl get pods --all-namespaces
```
-### Giving write access
+## Giving write access
At startup Flux generates a SSH key and logs the public key. Find
-the SSH public key by installing [fluxctl](../using/fluxctl.md) and
-runnning:
+the SSH public key by installing [fluxctl](../references/fluxctl.md) and
+running:
```sh
fluxctl identity
@@ -98,7 +96,13 @@ for more info on how to manage deploy keys.
`https://github.com/YOURUSER/flux-get-started/settings/keys/new` and
paste the key there.)
-### Committing a small change
+> **Note:** the SSH key must be configured to have R/W access to the
+> repository. More specifically, the SSH key must be able to create
+> and update tags. E.g. in Gitlab, that means it requires `Maintainer`
+> permissions. The `Developer` permission can create tags, but not
+> update them.
+
+## Committing a small change
In this example we are using a simple example of a webservice and
change its configuration to use a different message. The easiest
@@ -119,7 +123,7 @@ The default sync frequency is 5 minutes. This can be tweaked easily.
By observing the logs you can see when the change landed in in the
cluster.
-### Confirm the change landed
+## Confirm the change landed
To access our webservice and check out its welcome message, simply
run:
@@ -131,14 +135,13 @@ curl localhost:9898
Notice the updated `color` value in the JSON reply.
-### Conclusion
+## Conclusion
As you can see, the actual steps to set up Flux, get our app
deployed, give Flux access to it and see modifications land are
very straight-forward and are a quite natural work-flow.
As a next step, you might want to dive deeper into [how to
-control Flux](../using/fluxctl.md), check out [more sophisticated
-setups](./standalone-setup.md) or go through our hands-on
-tutorial about driving Flux, e.g.
-[automations, annotations and locks](../using/annotations-tutorial.md).
+control Flux](../references/fluxctl.md), or go through our
+hands-on tutorial about driving Flux, e.g.
+[automations, annotations and locks](driving-flux.md).
diff --git a/docs/tutorials/index.rst b/docs/tutorials/index.rst
new file mode 100644
index 000000000..eab53b2a5
--- /dev/null
+++ b/docs/tutorials/index.rst
@@ -0,0 +1,12 @@
+.. You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+Tutorials
+=========
+
+.. toctree::
+ :maxdepth: 1
+
+ get-started
+ get-started-helm
+ driving-flux
diff --git a/docs/using/index.rst b/docs/using/index.rst
deleted file mode 100644
index 3cff57133..000000000
--- a/docs/using/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. Flux documentation documentation master file, created by
- sphinx-quickstart on Wed Jun 12 16:13:18 2019.
- You can adapt this file completely to your liking, but it should at least
- contain the root `toctree` directive.
-
-Using Flux
-==============================================
-
-.. toctree::
- :maxdepth: 1
- :caption: Contents:
-
- annotations-tutorial
- fluxctl
- git-gpg
- monitoring
diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md
index 866508d53..08dbecb8b 100644
--- a/internal_docs/releasing.md
+++ b/internal_docs/releasing.md
@@ -4,7 +4,7 @@ The release process needs to do these things:
- create a new release on GitHub, with a tag
- push Docker image(s) to Docker Hub
- - possibly upload the [`fluxctl` binaries](/docs/using/fluxctl.md#binary-releases) to the GitHub release
+ - possibly upload the [`fluxctl` binaries](/docs/references/fluxctl.md#binary-releases) to the GitHub release
- make sure the version is entered into the checkpoint database so that up-to-date checks report back accurate information
- close out the GitHub milestone that was used to track the release
From ad5368646b97c3743fd93c2358b48d4e3638c372 Mon Sep 17 00:00:00 2001
From: Hidde Beydals <hello@hidde.co>
Date: Tue, 30 Jul 2019 18:52:03 +0200
Subject: [PATCH 2/3] Fixed broken links
---
chart/flux/Chart.yaml | 2 +-
chart/flux/templates/NOTES.txt | 2 +-
deploy/flux-deployment.yaml | 2 +-
git/errors.go | 2 +-
install/generated_templates.gogen.go | 8 ++++----
install/templates/flux-deployment.yaml.tmpl | 2 +-
remote/errors.go | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/chart/flux/Chart.yaml b/chart/flux/Chart.yaml
index 9fb256b33..6316484fe 100644
--- a/chart/flux/Chart.yaml
+++ b/chart/flux/Chart.yaml
@@ -11,6 +11,6 @@ maintainers:
- name: stefanprodan
email: stefan@weave.works
engine: gotpl
-icon: https://raw.githubusercontent.com/fluxcd/flux/master/docs/images/weave-flux.png
+icon: https://raw.githubusercontent.com/fluxcd/flux/master/docs/_files/weave-flux.png
keywords:
- gitops
diff --git a/chart/flux/templates/NOTES.txt b/chart/flux/templates/NOTES.txt
index c38c17d5a..1626bf019 100644
--- a/chart/flux/templates/NOTES.txt
+++ b/chart/flux/templates/NOTES.txt
@@ -3,7 +3,7 @@ Get the Git deploy key by either (a) running
kubectl -n {{ .Release.Namespace }} logs deployment/{{ .Release.Name }} | grep identity.pub | cut -d '"' -f2
or by (b) installing fluxctl through
-https://github.com/weaveworks/flux/blob/master/docs/using/fluxctl.md#installing-fluxctl
+https://github.com/weaveworks/flux/blob/master/docs/references/fluxctl.md#installing-fluxctl
and running:
fluxctl identity
diff --git a/deploy/flux-deployment.yaml b/deploy/flux-deployment.yaml
index 96e22e79e..570bfea93 100644
--- a/deploy/flux-deployment.yaml
+++ b/deploy/flux-deployment.yaml
@@ -35,7 +35,7 @@ spec:
# file, which you will need to do if you host your own git
# repo rather than using github or the like. You'll also need to
# mount it into the container, below. See
- # https://github.com/weaveworks/flux/blob/master/docs/install/standalone-setup.md#using-a-private-git-host
+ # https://github.com/weaveworks/flux/blob/master/docs//guides/use-private-git-host.md
# - name: ssh-config
# configMap:
# name: flux-ssh-config
diff --git a/git/errors.go b/git/errors.go
index a11087613..b55fc4bcd 100644
--- a/git/errors.go
+++ b/git/errors.go
@@ -16,7 +16,7 @@ We need to clone a git repo to proceed, and you haven't supplied
one. Please upload a config file, including a git repository URL, as
described in
- https://github.com/weaveworks/flux/blob/master/docs/using/fluxctl.md
+ https://github.com/weaveworks/flux/blob/master/docs/references/fluxctl.md
`,
}
diff --git a/install/generated_templates.gogen.go b/install/generated_templates.gogen.go
index 20afc50d1..2ebf80356 100644
--- a/install/generated_templates.gogen.go
+++ b/install/generated_templates.gogen.go
@@ -19,7 +19,7 @@ var templates = func() http.FileSystem {
fs := vfsgen۰FS{
"/": &vfsgen۰DirInfo{
name: "/",
- modTime: time.Date(2019, 7, 30, 9, 7, 53, 602764277, time.UTC),
+ modTime: time.Date(2019, 7, 30, 16, 51, 31, 100963419, time.UTC),
},
"/flux-account.yaml.tmpl": &vfsgen۰CompressedFileInfo{
name: "flux-account.yaml.tmpl",
@@ -30,10 +30,10 @@ var templates = func() http.FileSystem {
},
"/flux-deployment.yaml.tmpl": &vfsgen۰CompressedFileInfo{
name: "flux-deployment.yaml.tmpl",
- modTime: time.Date(2019, 7, 30, 9, 7, 53, 602764277, time.UTC),
- uncompressedSize: 5909,
+ modTime: time.Date(2019, 7, 30, 16, 51, 31, 100963419, time.UTC),
+ uncompressedSize: 5888,
- compressedContent: []byte("\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\xff\x9c\x58\x5f\x8f\x1b\xb7\x11\x7f\xbf\x4f\x31\x90\x1f\x6c\x03\xd2\xea\x94\x4b\x8b\x62\xd3\x0b\xe0\xd8\xb1\xeb\x3a\x3e\x1f\x7c\x75\x8b\x3e\x35\x14\x77\xa4\x25\xc4\x25\xb7\x1c\xee\x2a\x82\x90\xef\x1e\x0c\xb9\x7f\xb8\x92\xce\x17\xd8\x0f\xbe\x3b\xee\xfc\x9f\xe1\x6f\x66\xb8\x58\x2c\xae\x44\xad\xfe\x8d\x8e\x94\x35\x39\x88\xba\xa6\x65\xbb\xba\xda\x29\x53\xe4\xf0\x06\x6b\x6d\x0f\x15\x1a\x7f\x55\xa1\x17\x85\xf0\x22\xbf\x02\x30\xa2\xc2\x1c\x36\xba\xf9\xed\x78\x04\xb5\x81\xec\x4e\x54\x48\xb5\x90\x08\xbf\xff\xde\x7d\x0f\x7f\xe6\x70\x3c\x4e\xbf\x1e\x8f\x80\xa6\x60\x32\xaa\x51\xb2\x30\x87\xb5\x56\x52\x50\x0e\xab\x2b\x00\x42\x8d\xd2\x5b\xc7\x5f\x00\x2a\xe1\x65\xf9\x8b\x58\xa3\xa6\x78\x90\xea\x66\x6a\xef\x84\xc7\xed\x21\x7e\xf4\x87\x1a\x73\xf8\x8c\xd2\xa1\xf0\x78\x05\xe0\xb1\xaa\xb5\xf0\xd8\x09\x4b\x3c\xe0\x7f\xc2\x18\xeb\x85\x57\xd6\x0c\xc2\x01\x6a\x67\x2b\xf4\x25\x36\x94\x29\xbb\xac\xad\xf3\x39\xcc\x6e\xae\x6f\x56\x33\x78\x06\x1e\xb5\x4e\x28\xc0\x5b\x20\xe9\x44\x8d\xb0\xac\xd0\x3b\x25\x89\x9d\xab\xad\x32\xfe\x39\x01\x33\x67\x9d\x60\x3d\xf1\xe1\xc4\x0b\x80\x3e\x16\xe1\x77\x74\xad\x92\xf8\x4a\x4a\xdb\x18\x7f\x37\x25\x04\x68\xad\x6e\x2a\x1c\x44\x2d\x3a\x51\x5b\xe5\x17\x3b\x3c\x0c\x0a\x88\xa3\xe0\x47\x85\xfd\xc9\x28\x6f\xc1\x2c\x45\x48\x70\x42\x55\xe0\x46\x34\xda\x7f\xb4\x05\xe6\x70\xfd\xfd\xf5\x35\x3c\x83\x7d\x89\x06\x2a\xb6\x06\x0b\x70\x28\x8a\x85\x35\xfa\x30\x87\x3d\xc2\xde\x9a\xe7\x1e\xd6\x08\x62\xad\x91\xe3\x21\xcb\xca\x16\x57\x9d\xc0\x67\xf0\xaf\x52\x11\x28\x02\x01\xbe\xaa\x37\x04\x0d\x61\x01\x1b\xeb\x60\x8b\x06\x9d\xf0\xca\x6c\xe1\xe1\xe1\x1f\xb0\xc3\x03\x65\xf0\xde\xc0\x87\xbf\x11\xfc\x78\x0b\xab\x6c\x75\x3d\x1f\xa4\xf4\xba\xa3\x0b\x04\xc2\x61\x6a\x07\x59\x36\xc5\x20\x16\x20\x80\xb0\x16\x5c\x14\x5d\xa0\x60\x8f\x83\x18\x29\x0c\xec\x9d\xf2\x6c\x68\x76\x39\x7e\x5b\x34\x43\x30\xb0\xaa\xfd\xe1\x8d\x72\x69\x10\x2b\x2c\x54\x53\xe5\xf0\x11\x2b\xeb\x0e\xa9\x9f\x08\x1b\xab\xb5\xdd\xb3\x47\x9d\x6a\x45\xc1\xd5\x86\xf8\x4c\x80\x6c\xc8\xdb\x4a\x71\x04\x76\xc6\xee\xcd\xff\x4a\x4b\x9e\x06\x11\x1b\xa5\x71\x0e\xfb\x52\xc9\x12\x0e\xb6\x81\xbd\xd2\x3a\x3a\xe5\x2d\x14\x96\xef\x19\x1f\x33\x13\xff\xe2\xc0\xee\x0d\x9b\x3d\x08\x70\x58\x5b\x70\xc2\x97\xe8\xc0\x97\xc2\x74\x8a\xb7\xca\x97\xcd\x1a\x2c\x1f\x22\x68\xb5\xc3\x0c\xfe\x6b\x9b\xe7\x5a\x83\xd0\x64\x7b\x15\xd3\x60\x83\xf2\xa0\x8c\xb7\x81\x47\x5a\xe3\x85\x32\xe8\xe6\xb0\x46\x6d\xf7\x19\x3c\xe0\x18\xd5\xd2\xfb\x9a\xf2\xe5\x32\xea\xc9\xa4\xad\x96\x7b\x14\x2d\xee\xad\xdb\xd1\x92\x2b\x6d\xb9\xd6\x76\xbd\xac\x04\x79\x74\xcb\xc2\x4a\x5a\x2a\x43\x5e\x68\xbd\x24\x2f\x4c\x21\xb4\x35\xb8\x20\xf4\x4d\x9d\x55\xc5\xb3\x60\xf5\x42\x2c\x6a\xa7\x5a\xe1\x31\x94\x29\x3b\x3d\x28\xec\x53\x46\x54\x2e\xa4\x35\x1b\xb5\x1d\x3e\x01\xc4\x83\x8f\xa2\xce\x93\xc3\xf4\xbe\x2d\x12\xb6\x6f\x4d\x5f\xb6\x6b\xd6\xb8\x8c\x42\xc6\x2a\x7d\x32\x75\x7b\x45\x25\x9f\x94\xa2\x45\x10\x50\xa8\xcd\x06\x1d\x63\x6b\x2f\xa1\xbb\x7c\x23\x7e\x86\x4c\x45\x71\x69\xae\x18\x83\x5a\x55\x60\x9f\x9d\x8d\xda\x56\xa2\x1e\x0d\x51\xbe\x04\x61\x00\x8d\x77\x87\xe0\xc3\xaf\x91\xe8\xd7\x39\x08\x53\x40\x63\xa4\xad\x18\xd4\x03\x7f\xf4\xf6\x63\xc8\xba\x30\xc5\x20\x05\x4d\x1b\x24\x28\xa4\x2e\xed\x67\x19\xe0\x30\x7c\x43\x06\x12\xb6\x27\x33\x10\x00\xc3\x5b\x50\x15\xc3\x29\xbc\xbb\x7f\x17\xb0\x02\x5e\xb0\x5b\xa4\xb6\x46\x99\x51\x39\x3b\xd7\xa2\x53\x1b\x25\x03\xae\x43\xdd\xb8\xda\x12\xd2\xcb\x3f\x11\xc8\x41\x4a\x44\x99\x18\x45\x0e\x10\xeb\xfb\x13\x81\x03\xe1\xb6\xe3\x6d\x7e\x24\x62\xdb\x7a\xcb\x30\x43\x49\x68\xa6\x48\xfd\xec\x11\xac\x3e\xe7\xbb\x80\xd5\x7d\x38\x87\x0b\x7b\xd6\x26\x92\x46\xd2\x45\xdd\x61\x80\x53\x63\x61\x96\x73\xaf\x24\x3f\x03\x55\x89\x2d\xc6\xea\x67\x86\x0c\xde\x2a\x53\x04\x9f\x2b\x46\x1f\x87\x72\xac\xda\x88\x3c\x1a\x05\x21\x63\x4c\x60\xe5\x24\xf0\x38\x01\xc2\x0f\xf0\xc0\xd8\x50\x58\xb9\x43\x17\x20\xc2\x9d\x81\x84\x17\x43\xf8\xfa\x5c\xf2\x68\xc0\x63\x03\x6b\xf6\x62\x0b\x6c\x6d\x36\xd0\x04\x55\x39\x74\x42\x95\x0d\x62\x64\x11\x7e\xe4\xab\x6c\x75\x93\xdd\x4c\x69\xef\x1b\xad\xef\xad\x56\xf2\x90\xc3\xfb\xcd\x9d\xf5\xf7\x0e\x29\xf5\xc4\x21\xd9\xc6\x49\xa4\x14\xf2\x1d\xfe\xbf\x41\xf2\x93\x33\x00\x59\x37\x39\xfc\xe5\xba\x9a\x1c\x56\xa1\x2b\xe4\xf0\xd7\xef\x3f\xaa\x71\xa2\xb0\x2e\x65\x5e\x8c\xd9\xb9\x0f\xd3\xc5\xcd\xf5\x0d\x37\x59\x65\x36\xd6\x55\xa1\x6c\x85\x1e\xa8\x93\x1a\x9b\xc8\xb8\xdc\xf4\x21\x82\xf7\xbd\xf0\x65\x0e\x4b\xf4\x32\xc4\xa2\x58\x12\x95\x3c\xbd\xd8\x38\x4f\x81\xb6\xdd\xf5\xd8\xaa\x16\x0d\x28\x13\xc3\xf3\x9c\x22\x0f\x51\xb9\x9c\xdc\xea\x18\x05\x51\x7c\x32\xfa\x90\x83\x77\x0d\xb2\x34\xee\xec\xe1\x42\xad\x3b\x1c\xe2\x0a\xa8\xd1\x6d\xac\x93\xc8\x42\x63\x2b\xe7\x4e\xfe\x98\xe1\x69\xb7\x9d\xda\xde\x0a\xd7\xd9\x1e\xc9\xbe\xcd\xfc\xa4\x9c\xde\x1b\xa9\x9b\x70\xd1\x79\x20\x89\x78\xdc\x83\x40\xec\x78\x4f\x34\xe8\xbe\x45\xff\xc0\xac\x27\xcd\x73\x00\x03\x28\x50\x6a\xe1\x78\x10\x59\xdb\x36\xa9\xd5\xaf\x74\xad\x78\x9b\x53\xe7\x9d\xb5\x7e\x99\x11\x95\x8f\x3a\x20\xcc\x44\xeb\x6c\x44\xd4\x59\xd4\x3c\xef\x49\x12\x09\x68\x5a\xe5\xac\x09\xf8\x15\x5b\xc3\xec\xc3\x97\x9f\x7e\x7e\xfd\xe9\xee\xed\xfb\x77\xb3\x88\x58\x73\x8e\x87\x6d\xd1\xb9\x69\x7b\x49\xc4\x04\x44\x5e\x1f\x22\xf8\x7b\x7d\xc9\xc7\xb3\xbe\x70\xee\xe3\x58\x9c\x4c\xfc\xa8\xa3\x0c\xd1\x3c\x4e\xf7\xda\x18\x51\x92\xce\xd9\x59\x17\x72\x92\x88\x38\xed\xbf\x69\xd2\x43\xf3\xed\x07\x4a\x61\x40\x68\x8f\xce\xf0\xc0\x78\x66\xf1\xc6\xd9\x8a\xcb\xa2\x6f\xb0\x73\x10\xc4\xe5\xd6\x35\x01\x0e\x83\xb6\x72\x47\xe7\xc9\x46\xd3\xe6\x17\xe2\x32\x86\x7b\x12\x97\x56\xe8\x06\xcf\x62\xf2\x54\x11\x9f\xd6\x40\xdf\x22\xbe\x52\x01\xdc\xa1\xa6\x9d\xe9\x2b\xbd\xe9\x91\xba\x64\xaa\xd8\x8c\x27\x74\x53\x7c\x18\x8d\x66\x95\xf9\xc4\x87\x98\x86\xb8\x78\x60\xc1\x98\x29\x85\x2c\xb1\xe0\xc8\xa6\xa9\x1d\x86\x20\x4e\x22\x87\x65\x9e\x48\xb1\xae\x9b\x72\x12\x86\x6e\x71\x0a\x8c\xf3\xa0\x84\x07\x7e\x6a\xea\x5a\x1f\x38\x10\x94\x86\x62\x9c\x35\xfc\xde\xb2\x95\x0d\xa7\x34\x14\x5c\xd8\xf2\x42\x1e\xa0\xb4\xfb\xb0\xd4\x58\x63\x50\xfa\x30\x87\xf8\x69\xe8\x16\x8b\xc1\x81\x30\xa5\xb2\xf2\xdb\xe1\x28\xeb\x5a\x74\x46\xad\xcc\xa4\x6e\x78\x02\xce\x18\xbf\x74\x1a\x92\x2f\x14\xaf\xda\x18\x8a\xd7\x91\xf4\xfd\xfd\xc4\x29\xbe\x75\x84\x3e\x2c\x4d\xd3\xc4\x8e\x36\xf4\xf4\xbc\x9a\x7a\xc7\x94\x61\x8d\x49\x10\x38\xb5\xb8\xa3\xbe\xbd\x9a\xcc\x04\x8a\xa0\x6a\x28\xac\x75\x21\x7a\x0a\x8b\x58\x4d\xeb\x80\xeb\xa1\x1b\x87\x6d\xee\x45\xbf\x22\xbd\x4c\x6d\xe9\xef\x56\xac\x42\x1e\x22\x92\xa5\x6e\x62\x08\x63\x61\xc4\xf7\x45\xa1\xdc\xed\x19\xea\xa7\x66\x7d\x4e\x66\x81\x31\x79\x5f\x3e\xff\x12\xb7\x4e\x61\xb6\xf1\xdb\x3b\xe5\xc3\x26\x44\xca\x5b\x77\x18\xd0\xea\x2d\xcf\x31\x13\xe5\xdc\x83\x1a\xa7\x6f\x8f\x47\xc8\xde\x29\xcf\x92\xc2\xe3\xc5\x94\x62\xed\x84\x91\x65\x4f\xf4\x53\xf8\x2b\x3e\x63\xa8\x4d\x38\xe2\xbb\x41\x97\x38\x6b\xe1\x03\xdf\x43\x48\x03\xfd\xd3\x2a\x93\x30\xcc\xe6\xb3\xee\x35\x44\x13\xa6\xec\x3c\x09\x9c\xb7\xaa\xbd\x30\xa1\xfc\x1c\x72\x56\x65\x1c\x40\x2b\x61\xd4\x86\x47\x13\x2e\x50\x52\x05\xba\xe8\xeb\xc9\x90\x17\xb6\x38\x4b\x08\x8d\x29\xd0\x9d\x04\xd0\xa1\x16\x5e\xb5\x08\x75\x30\xab\x4b\xef\x76\x12\xc4\x93\x82\x1f\x9c\xa3\x66\x5d\x28\xb7\x9a\xc7\x9f\xdf\x0d\x4f\x3b\x63\x70\xc2\xd3\xcd\xa5\xe0\x84\xf7\x90\x3e\xaa\x3d\xd5\x05\x01\x5f\x08\xdd\x25\xfe\x86\xd0\x0d\x99\x63\x1a\xb8\xcc\xff\x73\x25\xd4\x45\x03\x90\x3f\xf4\x12\x7a\xaa\xf1\x71\xea\x22\xe8\x22\xdf\xd3\xbd\xe5\x80\xa2\x09\x0f\x1e\x1c\x27\xee\x06\xca\x9f\xec\x22\x69\xac\x3a\x5c\xed\x50\xf3\xf6\x2b\x30\xda\x73\x74\xb2\x98\xeb\xf6\xef\x3b\x3c\x80\x2a\x7e\x1c\xc8\xbe\xd2\x2a\x13\xab\x58\x84\xf0\x8d\xc3\xc9\x42\x74\x41\x57\xf8\x7c\x58\x0c\xf4\xf4\xb8\xef\x06\x7f\xf3\x7d\x00\x12\x48\x14\x06\x66\x4d\x4d\xde\xa1\xa8\x66\x3d\x60\x25\x42\x5e\x60\xb6\xcd\xe6\xf0\x1f\x9e\xf7\xe1\xb5\xb6\x4d\xf1\x32\x0b\xfb\x9e\xb7\x3b\x9e\xdf\x08\x6a\xe1\xbc\x92\x8d\x16\x0e\xba\x27\x87\x4e\xca\x29\xd6\x76\x5a\x6f\xf7\xc4\x2b\x85\x64\x59\x59\xd8\x23\xb2\xb8\x48\x88\x5a\x2d\x4f\xaa\x9f\xd9\x82\xa2\x5b\xb1\x96\xab\xef\x6e\xce\xff\x4f\x1d\x7e\x40\xd7\x5e\x78\xcd\xe3\xb1\x63\x6c\x34\x9c\xb5\x1f\x52\xc4\x13\x3b\x46\x4a\x17\x51\x17\x7d\xf2\x44\xf8\x3c\x79\x65\x4c\x9e\x0b\xd9\xc5\xb0\xcf\x86\xd6\x3f\xc5\x25\xad\xc8\xa3\x59\x74\x26\xdc\xe6\x37\xd7\x37\xab\xab\xae\xa2\x5f\x15\x85\x8a\x1b\x02\xe3\xd9\x2b\x6e\xe7\x13\xe8\x18\xbf\x8f\x2d\xed\x78\x04\x17\xd0\xf1\x09\xee\x45\x78\xab\x9d\xdc\x82\xf1\xb7\x5e\xc1\xa7\xba\x13\xff\xe6\xee\xa1\xef\x45\x34\xef\x46\xa4\xc6\x75\x9d\x09\x4c\x61\x3d\x81\x0d\xc4\x50\x89\x43\xd8\xac\x74\x3b\xee\xd8\x86\xb4\xb5\xbb\xa6\x06\x45\xd4\x20\x81\x35\x40\xb6\x42\xf8\xd0\xac\xd1\x19\xf4\x48\x10\x1e\x84\x68\x5c\xa1\x0b\x43\xfd\xf2\x36\xbb\xb3\x06\x67\xe9\x97\xd7\xc1\x80\x74\x89\x8e\xca\x69\xba\x57\xf7\xa3\x4e\xb0\x6f\xf2\x65\x98\xc2\x66\xab\xd9\xd5\x1f\x01\x00\x00\xff\xff\xa8\x51\xbb\xed\x15\x17\x00\x00"),
+ compressedContent: []byte("\x1f\x8b\x08\x00\x00\x00\x00\x00\x00\xff\x9c\x58\x5f\x6f\x1b\xb9\x11\x7f\xf7\xa7\x18\x28\x0f\x49\x00\x69\x65\x9d\xaf\x45\xb1\x57\x1f\x90\x4b\x2e\x69\x9a\x8b\x63\xc4\x4d\x8b\x3e\xf5\x28\xee\x48\x4b\x88\x4b\x6e\x39\xa4\x74\x82\x71\xdf\xfd\x30\xe4\xfe\xe1\x5a\x72\x7c\x48\x1e\x62\x9b\x3b\xff\x67\xf8\x9b\x19\x2e\x16\x8b\x0b\xd1\xaa\x7f\xa3\x23\x65\x4d\x09\xa2\x6d\x69\xb9\x5f\x5d\xec\x94\xa9\x4a\x78\x83\xad\xb6\xc7\x06\x8d\xbf\x68\xd0\x8b\x4a\x78\x51\x5e\x00\x18\xd1\x60\x09\x1b\x1d\x7e\xbb\xbf\x07\xb5\x81\xe2\x46\x34\x48\xad\x90\x08\xbf\xff\xde\x7d\x8f\x7f\x96\x70\x7f\x3f\xfd\x7a\x7f\x0f\x68\x2a\x26\xa3\x16\x25\x0b\x73\xd8\x6a\x25\x05\x95\xb0\xba\x00\x20\xd4\x28\xbd\x75\xfc\x05\xa0\x11\x5e\xd6\xbf\x88\x35\x6a\x4a\x07\xb9\x6e\xa6\xf6\x4e\x78\xdc\x1e\xd3\x47\x7f\x6c\xb1\x84\xcf\x28\x1d\x0a\x8f\x17\x00\x1e\x9b\x56\x0b\x8f\x9d\xb0\xcc\x03\xfe\x27\x8c\xb1\x5e\x78\x65\xcd\x20\x1c\xa0\x75\xb6\x41\x5f\x63\xa0\x42\xd9\x65\x6b\x9d\x2f\x61\x76\x75\x79\xb5\x9a\xc1\x33\xf0\xa8\x75\x46\x01\xde\x02\x49\x27\x5a\x84\x65\x83\xde\x29\x49\xec\x5c\x6b\x95\xf1\xcf\x09\x98\xb9\xe8\x04\xeb\x89\x0f\x0f\xbc\x00\xe8\x63\x11\x7f\x47\xb7\x57\x12\x5f\x49\x69\x83\xf1\x37\x53\x42\x80\xbd\xd5\xa1\xc1\x41\xd4\xa2\x13\xb5\x55\x7e\xb1\xc3\xe3\xa0\x80\x38\x0a\x7e\x54\xd8\x9f\x8c\xf2\x16\xcc\x52\xc5\x04\x67\x54\x15\x6e\x44\xd0\xfe\xa3\xad\xb0\x84\xcb\xef\x2f\x2f\xe1\x19\x1c\x6a\x34\xd0\xb0\x35\x58\x81\x43\x51\x2d\xac\xd1\xc7\x39\x1c\x10\x0e\xd6\x3c\xf7\xb0\x46\x10\x6b\x8d\x1c\x0f\x59\x37\xb6\xba\xe8\x04\x3e\x83\x7f\xd5\x8a\x40\x11\x08\xf0\x4d\xbb\x21\x08\x84\x15\x6c\xac\x83\x2d\x1a\x74\xc2\x2b\xb3\x85\xbb\xbb\x7f\xc0\x0e\x8f\x54\xc0\x7b\x03\x1f\xfe\x46\xf0\xe3\x35\xac\x8a\xd5\xe5\x7c\x90\xd2\xeb\x4e\x2e\x10\x08\x87\xb9\x1d\x64\xd9\x14\x83\x58\x81\x00\xc2\x56\x70\x51\x74\x81\x82\x03\x0e\x62\xa4\x30\x70\x70\xca\xb3\xa1\xc5\xf9\xf8\x6d\xd1\x0c\xc1\xc0\xa6\xf5\xc7\x37\xca\xe5\x41\x6c\xb0\x52\xa1\x29\xe1\x23\x36\xd6\x1d\x73\x3f\x11\x36\x56\x6b\x7b\x60\x8f\x3a\xd5\x8a\xa2\xab\x81\xf8\x4c\x80\x0c\xe4\x6d\xa3\x38\x02\x3b\x63\x0f\xe6\x7f\xb5\x25\x4f\x83\x88\x8d\xd2\x38\x87\x43\xad\x64\x0d\x47\x1b\xe0\xa0\xb4\x4e\x4e\x79\x0b\x95\xe5\x7b\xc6\xc7\xcc\xc4\xbf\x38\xb0\x07\xc3\x66\x0f\x02\x1c\xb6\x16\x9c\xf0\x35\x3a\xf0\xb5\x30\x9d\xe2\xad\xf2\x75\x58\x83\xe5\x43\x04\xad\x76\x58\xc0\x7f\x6d\x78\xae\x35\x08\x4d\xb6\x57\x31\x0d\x36\x28\x0f\xca\x78\x1b\x79\xa4\x35\x5e\x28\x83\x6e\x0e\x6b\xd4\xf6\x50\xc0\x1d\x8e\x51\xad\xbd\x6f\xa9\x5c\x2e\x93\x9e\x42\xda\x66\x79\x40\xb1\xc7\x83\x75\x3b\x5a\x72\xa5\x2d\xd7\xda\xae\x97\x8d\x20\x8f\x6e\x59\x59\x49\xcb\xe5\x36\xa8\x0a\x69\x19\x08\x17\xad\x53\x7b\xe1\x31\x96\x23\x3b\x57\x34\xd5\x20\xbb\xcf\x0e\x51\xbd\x90\xd6\x6c\xd4\x76\xf8\x04\x90\x0e\x3e\x8a\xb6\xcc\x0e\xf3\xab\xb5\xc8\xd8\xbe\x35\x53\xc5\x2e\xac\x71\x99\x84\x8c\x05\xf9\x64\x96\x0e\x8a\x6a\x3e\xa9\xc5\x1e\x41\x40\xa5\x36\x1b\x74\x0c\xa3\xbd\x84\xee\x9e\x8d\x50\x19\x93\x92\xc4\xe5\x69\x61\xb8\xd9\xab\x0a\xfb\x44\x6c\xd4\xb6\x11\xed\x68\x88\xf2\x35\x08\x03\x68\xbc\x3b\x46\x1f\x7e\x4d\x44\xbf\xce\x41\x98\x0a\x82\x91\xb6\x61\xfc\x8e\xfc\xc9\xdb\x8f\x31\xc1\xc2\x8c\x61\x46\xb3\x8f\x12\x14\x52\x97\xe1\x93\x0c\x70\x18\xbe\x21\x03\x19\xdb\x93\x19\x88\xd8\xe0\x2d\xa8\x86\x91\x13\xde\xdd\xbe\x8b\xb0\x00\x2f\xd8\x2d\x52\x5b\xa3\xcc\xa8\x9c\x9d\xdb\xa3\x53\x1b\x25\x23\x84\x43\x1b\x5c\x6b\x09\xe9\xe5\x9f\x08\xe4\x20\x25\x01\x4a\x8a\x22\x07\x88\xf5\xfd\x89\xc0\x81\x70\xdb\xf1\xe2\x3e\x12\xb1\x6d\xbb\x65\x44\xa1\x2c\x34\x53\x50\x7e\xf6\x08\x2c\x9f\xf2\x9d\x81\xe5\x3e\x9c\xc3\xdd\x3c\xe9\x08\x59\xcf\xe8\xa2\xee\x30\x22\xa7\xb1\x30\x2b\xb9\x2d\x92\x9f\x81\x6a\xc4\x16\x53\xf5\x33\x43\x01\x6f\x95\xa9\xa2\xcf\x0d\x03\x8d\x43\x39\x56\x6d\x02\x19\x8d\x82\x90\xe1\x24\xb2\x72\x12\x78\x72\x00\xe1\x07\x24\x60\x18\xa8\xac\xdc\xa1\x8b\x68\xe0\x4e\xf0\xc0\x8b\x21\x7c\x7d\x2e\x79\x0a\xe0\x09\x81\x35\x7b\xb1\x05\xb6\xb6\x18\x68\xa2\xaa\x12\x3a\xa1\xca\x46\x31\xb2\x8a\x3f\xca\x55\xb1\xba\x2a\xae\xa6\xb4\xb7\x41\xeb\x5b\xab\x95\x3c\x96\xf0\x7e\x73\x63\xfd\xad\x43\xca\x3d\x71\x48\x36\x38\x89\x94\xa3\xbb\xc3\xff\x07\x24\x3f\x39\x03\x90\x6d\x28\xe1\x2f\x97\xcd\xe4\xb0\x89\x0d\xa0\x84\xbf\x7e\xff\x51\x8d\xc3\x83\x75\x39\xf3\x62\xcc\xce\x6d\x1c\x24\xae\x2e\xaf\xb8\x9f\x2a\xb3\xb1\xae\x89\x65\x2b\xf4\x40\x9d\xd5\xd8\x44\xc6\xf9\xfe\x0e\x09\xa7\x6f\x85\xaf\x4b\x58\xa2\x97\x31\x16\xd5\x92\xa8\xe6\x41\xc5\xa6\xd1\x09\xb4\xed\xae\xc7\x56\xed\xd1\x80\x32\x29\x3c\xcf\x29\xf1\x10\xd5\xcb\xc9\xad\x4e\x51\x10\xd5\x27\xa3\x8f\x25\x78\x17\x90\xa5\x71\x13\x8f\x17\x6a\xdd\xe1\x10\x57\x40\x8b\x6e\x63\x9d\x44\x16\x9a\xba\x36\x37\xed\xc7\x0c\xcf\x1b\xeb\xd4\xf6\xbd\x70\x9d\xed\x89\xec\xdb\xcc\xcf\xca\xe9\xbd\x91\x3a\xc4\x8b\xce\xb3\x47\xc2\xe3\x1e\x04\x52\x73\x7b\xa2\x17\xf7\xdd\xf8\x07\x66\x7d\xd0\x27\x07\x30\x80\x0a\xa5\x16\x8e\x67\x8e\xb5\xdd\x67\xb5\xfa\x95\xae\x95\x6e\x73\xee\xbc\xb3\xd6\x2f\x0b\xa2\xfa\x51\x07\x84\x99\x68\x9d\x8d\x88\x3a\x4b\x9a\xe7\x3d\x49\x26\x01\xcd\x5e\x39\x6b\x22\x7e\xa5\xd6\x30\xfb\xf0\xe5\xa7\x9f\x5f\x7f\xba\x79\xfb\xfe\xdd\x2c\x21\xd6\x9c\xe3\x61\xf7\xe8\xdc\xb4\xbd\x64\x62\x22\x22\xaf\x8f\x09\xfc\xbd\x3e\xe7\xe3\x49\x5f\x38\xf5\x71\x2c\x4e\x26\x7e\xd4\x51\x86\x68\x9e\x9c\x7b\x6d\x8c\x28\x59\xe7\xec\xac\x8b\x39\xc9\x44\x3c\xec\xbf\x79\xd2\x63\xf3\xed\x67\x47\x61\x40\x68\x8f\xce\xf0\x6c\x78\x62\xf1\xc6\xd9\x86\xcb\xa2\x6f\xb0\x73\x10\xc4\xe5\xd6\x35\x01\x0e\x83\xb6\x72\x47\xa7\xc9\x46\xb3\x2f\xcf\xc4\x65\x0c\xf7\x24\x2e\x7b\xa1\x03\x9e\xc4\xe4\xa9\x22\x7e\x58\x03\x7d\x8b\xf8\x4a\x05\x70\x87\x9a\x76\xa6\xaf\xf4\xa6\x47\xea\x92\xa9\x52\x33\x9e\xd0\x4d\xf1\x61\x34\x9a\x55\x96\x13\x1f\x52\x1a\xd2\x8e\x81\x15\x63\xa6\x14\xb2\xc6\x8a\x23\x9b\xa7\x76\x18\x82\x38\x89\x1c\x96\x79\x26\xc5\xba\x6e\xca\xc9\x18\xba\x1d\x29\x32\xce\xa3\x12\x9e\xed\x29\xb4\xad\x3e\x72\x20\x28\x0f\xc5\x38\x6b\xf8\x83\x65\x2b\x03\xa7\x34\x16\x5c\x5c\xe8\x62\x1e\xa0\xb6\x87\xb8\xbf\x58\x63\x50\xfa\x38\x87\xf8\x69\xe8\x16\x8b\xc1\x81\x38\xa8\xb2\xf2\xeb\xe1\xa8\xe8\x5a\x74\x41\x7b\x59\x48\x1d\x78\xd8\x2d\x18\xbf\x74\x1e\x92\x2f\x94\xae\xda\x18\x8a\xd7\x89\xf4\xfd\xed\xc4\x29\xbe\x75\x84\x3e\xee\x47\xd3\xc4\x8e\x36\xf4\xf4\xbc\x85\x7a\xc7\x94\x71\x63\xc9\x10\x38\xb7\xb8\xa3\xbe\xbe\x98\xcc\x04\x8a\xa0\x09\x14\x37\xb8\x18\x3d\x85\x55\xaa\xa6\x75\xc4\xf5\xd8\x8d\xe3\xe2\xf6\xa2\xdf\x86\x5e\xe6\xb6\xf4\x77\x2b\x55\x21\x0f\x11\xd9\xfe\x36\x31\x84\xb1\x30\xe1\xfb\xa2\x52\xee\xfa\x04\xf5\x73\xb3\x3e\x67\xb3\xc0\x98\xbc\x2f\x9f\x7f\x49\x0b\xa6\x30\xdb\xf4\xed\x9d\xf2\x71\xe9\x21\xe5\xad\x3b\x0e\x68\xf5\x96\xe7\x98\x89\x72\xee\x41\xc1\xe9\xeb\xfb\x7b\x28\xde\x29\xcf\x92\xe2\x3b\xc5\x94\x62\xed\x84\x91\x75\x4f\xf4\x53\xfc\x2b\xbd\x58\xa8\x4d\x3c\xe2\xbb\x41\xe7\x38\x5b\xe1\x23\xdf\x5d\x4c\x03\xfd\xd3\x2a\x93\x31\xcc\xe6\xb3\xee\xe1\x43\x13\xe6\xec\x3c\x09\x9c\xb6\xaa\x83\x30\xb1\xfc\x1c\x72\x56\x65\x1a\x40\x1b\x61\xd4\x86\x47\x13\x2e\x50\x52\x15\xba\xe4\xeb\x83\x21\x2f\x2e\x6c\x96\x10\x82\xa9\xd0\x3d\x08\xa0\x43\x2d\xbc\xda\x23\xb4\xd1\xac\x2e\xbd\xdb\x49\x10\x1f\x14\xfc\xe0\x1c\x85\x75\xa5\xdc\x6a\x9e\x7e\x7e\x37\xbc\xe2\x8c\xc1\x89\xaf\x34\xe7\x82\x13\x9f\x3e\xfa\xa8\xf6\x54\x67\x04\x7c\x21\x74\xe7\xf8\x03\xa1\x1b\x32\xc7\x34\x70\x9e\xff\xe7\x46\xa8\xb3\x06\x20\x7f\xe8\x25\xf4\x54\xe3\x3b\xd4\x59\xd0\x45\xbe\xa7\x07\xcb\x01\x45\x13\xdf\x36\x38\x4e\xdc\x0d\x94\x7f\xb0\x8b\xe4\xb1\xea\x70\xb5\x43\xcd\xeb\xaf\xc0\x68\xcf\xd1\xc9\x62\xae\xeb\xbf\xef\xf0\x08\xaa\xfa\x71\x20\xfb\x4a\xab\xcc\xac\x62\x11\xc2\x07\x87\x93\x85\xe8\x8c\xae\xf8\xf9\xb8\x18\xe8\xe9\x71\xdf\x0d\xfe\xe6\xfb\x00\x64\x90\x28\x0c\xcc\x42\x4b\xde\xa1\x68\x66\x3d\x60\x65\x42\x5e\x60\xb1\x2d\xe6\xf0\x1f\x9e\xf7\xe1\xb5\xb6\xa1\x7a\x59\xc4\x7d\xcf\xdb\x1d\xcf\x6f\x04\xad\x70\x5e\xc9\xa0\x85\x83\xee\x75\xa1\x93\xf2\x10\x6b\x3b\xad\xd7\x07\xe2\x95\x42\xb2\xac\x22\xee\x11\x45\x5a\x24\x44\xab\x96\x0f\xaa\x9f\xd9\xa2\xa2\x6b\xb1\x96\xab\xef\xae\x4e\xff\xcf\x1d\xbe\x43\xb7\x3f\xf3\x70\xc7\x63\xc7\xd8\x68\x38\x6b\x3f\xe4\x88\x27\x76\x8c\x94\x2e\xa1\x2e\xfa\xec\x35\xf0\x79\xf6\xa0\x98\xbd\x0c\xb2\x8b\x71\x9f\x8d\xad\x7f\x8a\x4b\x5a\x91\x47\xb3\xe8\x4c\xb8\x2e\xaf\x2e\xaf\x56\x17\x5d\x45\xbf\xaa\x2a\x95\x36\x04\xc6\xb3\x57\xdc\xce\x27\xd0\x31\x7e\x1f\x5b\xda\xfd\x3d\xb8\x88\x8e\x4f\x70\x2f\xe2\xb3\xec\xe4\x16\x8c\xbf\xf5\x0a\x3e\xb5\x9d\xf8\x37\x37\x77\x7d\x2f\xa2\x79\x37\x22\x05\xd7\x75\x26\x30\x95\xf5\x04\x36\x12\x43\x23\x8e\x71\xb3\xd2\xfb\x71\xc7\x36\xa4\xad\xdd\x85\x16\x14\x51\x40\x02\x6b\x80\x6c\x83\xf0\x21\xac\xd1\x19\xf4\x48\x2c\x3d\xb4\x34\xae\xd0\x95\xa1\x7e\x79\x9b\xdd\x58\x83\xb3\xfc\xcb\xeb\x68\x40\xbe\x44\x27\xe5\x34\xdd\xab\xfb\x51\x27\xda\x37\xf9\x32\x4c\x61\xb3\xd5\xec\xe2\x8f\x00\x00\x00\xff\xff\xf1\x12\x73\x2a\x00\x17\x00\x00"),
},
"/flux-secret.yaml.tmpl": &vfsgen۰CompressedFileInfo{
name: "flux-secret.yaml.tmpl",
diff --git a/install/templates/flux-deployment.yaml.tmpl b/install/templates/flux-deployment.yaml.tmpl
index 2b08fd64c..ed28285dc 100644
--- a/install/templates/flux-deployment.yaml.tmpl
+++ b/install/templates/flux-deployment.yaml.tmpl
@@ -36,7 +36,7 @@ spec:
# file, which you will need to do if you host your own git
# repo rather than using github or the like. You'll also need to
# mount it into the container, below. See
- # https://github.com/weaveworks/flux/blob/master/docs/install/standalone-setup.md#using-a-private-git-host
+ # https://github.com/weaveworks/flux/blob/master/docs//guides/use-private-git-host.md
# - name: ssh-config
# configMap:
# name: flux-ssh-config
diff --git a/remote/errors.go b/remote/errors.go
index 0383db007..58cc54bdc 100644
--- a/remote/errors.go
+++ b/remote/errors.go
@@ -22,7 +22,7 @@ and try the operation again.
Otherwise, please consult the installation instructions in our
documentation:
- https://github.com/weaveworks/flux/blob/master/docs/install/index.md
+ https://github.com/weaveworks/flux/blob/master/docs/get-started/index.rst
If you are still stuck, please log an issue:
From 51108e21ca0d61d432fe8bec89b05cde2939978d Mon Sep 17 00:00:00 2001
From: Hidde Beydals <hello@hidde.co>
Date: Wed, 31 Jul 2019 10:48:49 +0200
Subject: [PATCH 3/3] Update link to 'advanced' get-started repository
---
docs/tutorials/get-started-helm.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/tutorials/get-started-helm.md b/docs/tutorials/get-started-helm.md
index 2e67a944f..a57e76c12 100644
--- a/docs/tutorials/get-started-helm.md
+++ b/docs/tutorials/get-started-helm.md
@@ -185,5 +185,5 @@ very straight-forward and are a quite natural workflow.
## A more advanced setup
-For a more advanced Helm setup, take a look at the [gitops-helm
-repository](https://github.com/stefanprodan/gitops-helm).
+For a more advanced Helm setup, take a look at the
+[`fluxcd/helm-operator-get-started` repository](https://github.com/fluxcd/helm-operator-get-started).