From b8fa18353e63b221dffd453d88def790ad8d808c Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Tue, 26 Feb 2019 21:31:31 -0500 Subject: [PATCH 01/12] takes guesswork out of secret key having the name `identity` --- site/fluxctl.md | 14 +++++++++++++- site/standalone-setup.md | 14 +++++++++++++- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/site/fluxctl.md b/site/fluxctl.md index 7770733ec..cc1aeea87 100644 --- a/site/fluxctl.md +++ b/site/fluxctl.md @@ -142,7 +142,19 @@ can restart `flux` and it will continue to use the same key. Create a Kubernetes Secret from a private key: ```sh -kubectl create secret generic flux-git-deploy --from-file /path/to/identity +kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/identity +``` + +this will result in a secret that has the structure: + +```yaml + apiVersion: v1 + data: + identity: + kind: Secret + type: Opaque + metadata: + ... ``` Now add the secret to the `flux-deployment.yaml` manifest: diff --git a/site/standalone-setup.md b/site/standalone-setup.md index 264dd5306..0c74b4671 100644 --- a/site/standalone-setup.md +++ b/site/standalone-setup.md @@ -62,7 +62,19 @@ fluxctl identity Create a Kubernetes Secret from a private key: ```sh -kubectl create secret generic flux-git-deploy --from-file=identity=/path/to/private_key +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: + kind: Secret + type: Opaque + metadata: + ... ``` The Kubernetes deployment configuration file From e4e1b9abea39c5a4ab7fc0dcb2a0e3926d3a6184 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Tue, 26 Feb 2019 21:32:50 -0500 Subject: [PATCH 02/12] reinforces that the key flux needs is the private key --- site/faq.md | 10 +++++----- site/fluxctl.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/site/faq.md b/site/faq.md index 422235ab0..9201e73e2 100644 --- a/site/faq.md +++ b/site/faq.md @@ -241,9 +241,9 @@ First delete the secret (if it exists): `kubectl delete secret flux-git-deploy` -Then create a new secret named `flux-git-deploy`, using your key as the content of the secret: +Then create a new secret named `flux-git-deploy`, using your private key as the content of the secret: -`kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/key` +`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): @@ -445,11 +445,11 @@ 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"`. +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. +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/site/fluxctl.md b/site/fluxctl.md index cc1aeea87..80bf17e69 100644 --- a/site/fluxctl.md +++ b/site/fluxctl.md @@ -142,7 +142,7 @@ can restart `flux` and it will continue to use the same key. Create a Kubernetes Secret from a private key: ```sh -kubectl create secret generic flux-git-deploy --from-file=identity=/full/path/to/identity +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: From bdf96d3609c1c869c87f90a539cac9fdce44c599 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Tue, 26 Feb 2019 21:44:08 -0500 Subject: [PATCH 03/12] clarifies that Weave Cloud is not just the UI for Flux --- site/how-it-works.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/site/how-it-works.md b/site/how-it-works.md index 3b058f5d7..ade8a564f 100644 --- a/site/how-it-works.md +++ b/site/how-it-works.md @@ -3,8 +3,8 @@ title: How Weave Flux Works menu_order: 20 --- -This page describes the goals of flux, how it achieves them and -significant architectural decisions. It is intentionally high level +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 @@ -23,9 +23,9 @@ 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 also provides a CLI and a UI (in Weave Cloud) to perform these -operations manually. Flux is flexible enough to fit into any development -process. +Flux provides a CLI (`fluxctl`) and a UI (as a component of Weave Cloud) +to perform these operations manually. Flux is flexible enough to fit +into any development process. # Implementation Overview @@ -70,10 +70,10 @@ In order to access private registries, credentials may be required. ## Deployment of Images -Flux will only deploy different images. It will not re-deploy images +Flux will only deploy different images. It will not re-deploy images with the same tag. -Once a list of new images have been established, it will alter the +Once a list of new images have been established, it will alter the configuration of the cluster to deploy the new images. Images can be "locked" to a specific version. "locked" images won't be From ebc2d0aee34a1d59ce955291bda3834adee385d8 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Wed, 27 Feb 2019 10:14:19 -0500 Subject: [PATCH 04/12] clarifies that the demo namespace is where things deployed by flux go --- site/helm-get-started.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/site/helm-get-started.md b/site/helm-get-started.md index 8c6fb5ba8..6424a656a 100644 --- a/site/helm-get-started.md +++ b/site/helm-get-started.md @@ -72,7 +72,7 @@ kubectl apply -f https://raw.githubusercontent.com/weaveworks/flux/master/deploy In this next step you install Weave 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 + 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 Weave Flux and its Helm Operator by specifying your fork URL: @@ -137,7 +137,8 @@ paste the key there.) Once Flux has confirmed access to the repository, it will start deploying the workloads of `flux-get-started`. After a while you -will be able to see the Helm releases listed like so: +will be able to see the Helm releases deployed by Flux (which are +deployed into the `demo` namespace) listed like so: ```sh helm list --namespace demo @@ -177,7 +178,8 @@ The default sync frequency for Flux using the Helm chart is five minutes. This can be tweaked easily. By observing the logs you can see when the change landed in the cluster. -Confirm the change landed with: +Confirm the change landed by checking the `demo` namespace that +Flux is deploying to: ```sh kubectl describe -n demo deployment/mongodb | grep Image From e0c5a7cd7bc30c4549e68341b86e3ce20d10a365 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Wed, 27 Feb 2019 10:16:03 -0500 Subject: [PATCH 05/12] nitpick: Github -> GitHub --- site/annotations-tutorial.md | 2 +- site/get-started.md | 6 +++--- site/helm-get-started.md | 6 +++--- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/site/annotations-tutorial.md b/site/annotations-tutorial.md index 356bb8321..ce1ce3ebe 100644 --- a/site/annotations-tutorial.md +++ b/site/annotations-tutorial.md @@ -30,7 +30,7 @@ And update the following line --git-url=git@github.com:weaveworks/flux-get-started ``` -to point to your fork, e.g. if your Github Login is `baloothebear`, the line +to point to your fork, e.g. if your GitHub Login is `baloothebear`, the line above should be ```yaml diff --git a/site/get-started.md b/site/get-started.md index c5be68df7..b13a14609 100644 --- a/site/get-started.md +++ b/site/get-started.md @@ -62,7 +62,7 @@ $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 +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. ## Deploying Flux to the cluster @@ -101,7 +101,7 @@ access**, paste the Flux public key and click **Add key**. See the (GitHub docs)[https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys] for more info on how to manage deploy keys. -(Or replace `YOURUSER` with your Github ID in this url: +(Or replace `YOURUSER` with your GitHub ID in this url: `https://github.com/YOURUSER/flux-get-started/settings/keys/new` and paste the key there.) @@ -113,7 +113,7 @@ way is to edit your fork of `flux-get-started` and change the `PODINFO_UI_COLOR` Replace `YOURUSER` in `https://github.com/YOURUSER/flux-get-started/blob/master/workloads/podinfo-dep.yaml` -with your Github ID), open the URL in your browser, edit the file, +with your GitHub ID), open the URL in your browser, edit the file, change the env var value and commit the file. You can check out the Flux logs with: diff --git a/site/helm-get-started.md b/site/helm-get-started.md index 6424a656a..e1e03929d 100644 --- a/site/helm-get-started.md +++ b/site/helm-get-started.md @@ -72,7 +72,7 @@ kubectl apply -f https://raw.githubusercontent.com/weaveworks/flux/master/deploy In this next step you install Weave 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 + 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 Weave Flux and its Helm Operator by specifying your fork URL: @@ -131,7 +131,7 @@ Open GitHub, navigate to your fork, go to **Setting > Deploy keys**, click on **Add deploy key**, give it a `Title`, check **Allow write access**, paste the Flux public key and click **Add key**. -(Or replace `YOURUSER` with your Github ID in this url: +(Or replace `YOURUSER` with your GitHub ID in this url: `https://github.com/YOURUSER/flux-get-started/settings/keys/new` and paste the key there.) @@ -155,7 +155,7 @@ The easiest way is to update your fork of `flux-get-started` and change the `image` argument. Replace `YOURUSER` in `https://github.com/YOURUSER/flux-get-started/edit/master/releases/mongodb.yaml` -with your Github ID, open the URL in your browser, edit the file, +with your GitHub ID, open the URL in your browser, edit the file, change the `tag:` line to the following: ```yaml From 3b2c814984feec6dd4167cc4174e83e92ae00d1f Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Thu, 28 Feb 2019 10:05:38 -0500 Subject: [PATCH 06/12] adds links to fluxctl from other files --- internal_docs/releasing.md | 2 +- site/annotations-tutorial.md | 2 +- site/faq.md | 4 +++- site/how-it-works.md | 2 +- 4 files changed, 6 insertions(+), 4 deletions(-) diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md index 1d35921ec..1b9a7a69e 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 quay.io - - possibly upload the `fluxctl` binaries to the GitHub release + - possibly upload the [`fluxctl` binaries](/site/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 diff --git a/site/annotations-tutorial.md b/site/annotations-tutorial.md index ce1ce3ebe..b971734cd 100644 --- a/site/annotations-tutorial.md +++ b/site/annotations-tutorial.md @@ -93,7 +93,7 @@ weaveworks/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 ` option for specifying the right +it. `fluxctl` has the [`--k8s-fwd-ns ` option](fluxctl.md#Connectingfluxctltothedaemon) for specifying the right namespace. ### Connecting to your git config diff --git a/site/faq.md b/site/faq.md index 9201e73e2..34362ff09 100644 --- a/site/faq.md +++ b/site/faq.md @@ -136,7 +136,9 @@ applying the command. This is done to ensure that git remains the single source For example, if you use the following `fluxctl` command: - fluxctl release --controller=deployment/foo --update-image=bar:v2 +```sh +fluxctl release --controller=deployment/foo --update-image=bar:v2 +``` The image tag will be updated in the git repository upon applying the command. diff --git a/site/how-it-works.md b/site/how-it-works.md index ade8a564f..08f7a5c9f 100644 --- a/site/how-it-works.md +++ b/site/how-it-works.md @@ -23,7 +23,7 @@ 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`) and a UI (as a component of Weave Cloud) +Flux provides a CLI ([`fluxctl`](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. From 17262ecd31811209c337a94ef73cf3cea722f7fe Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Thu, 28 Feb 2019 14:45:39 -0500 Subject: [PATCH 07/12] adds beginnings of get-started-developing guide --- CONTRIBUTING.md | 2 + site/get-started-developing.md | 181 +++++++++++++++++++++++++++++++++ 2 files changed, 183 insertions(+) create mode 100644 site/get-started-developing.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88cb36fcd..d4267f0a7 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -58,6 +58,8 @@ This is a rough outline of how to prepare a contribution: Refer to the [building doc](site/building.md) to find out how to build from source. +Refer to the [up-and-running with Flux Development](site/get-started-developing.md) doc for a walkthrough on developing Flux locally. + ### How to run the test suite You can run the unit tests by simply doing diff --git a/site/get-started-developing.md b/site/get-started-developing.md new file mode 100644 index 000000000..f94a88a89 --- /dev/null +++ b/site/get-started-developing.md @@ -0,0 +1,181 @@ +# Get Started Developing Flux + +This tutorial is going to walk you through one possible workflow for making a small (actually, tiny) change to flux and 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. `quay.io/weaveworks/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. 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](site/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. 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: + ``` + 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`: + + ``` + 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:/flux.git` replacing `` with your GitHub username. + + In the same terminal you ran `eval $(minikube docker-env)`, run `dep ensure` 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: + ``` + Successfully built 606610e0f4ef + Successfully tagged quay.io/weaveworks/flux:latest + Successfully tagged quay.io/weaveworks/flux:master-a86167e4 + ``` + This confirms that a new docker image was tagged for your image. + +1. Open up [`deploy/flux-deployment.yaml`](deploy/flux-deployment.yaml) and update the image at `spec.template.spec.containers[0].image` to be simply `quay.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: quay.io/weaveworks/flux + imagePullPolicy: IfNotPresent + args: + - --git-url=git@github.com:/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: + + ``` + 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: + ``` + ts=2019-02-28T18:58:45.091531939Z caller=warming.go:268 component=warmer info="refreshing image" image=quay.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=quay.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](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 `quay.io/weaveworks/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 `quay.io/weaveworks/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 `:-` 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! \ No newline at end of file From 08c2b422b91addec9fb1aef03c87f28558b50ffc Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Fri, 1 Mar 2019 13:42:04 -0500 Subject: [PATCH 08/12] nitpick: `flux` -> `Flux` for those bean-counters in the audience I timed it: this change took 2m21s --- CHANGELOG.md | 16 +++++----- chart/flux/CHANGELOG.md | 14 ++++----- chart/flux/README.md | 30 +++++++++---------- .../kubernetes/resource/fluxhelmrelease.go | 2 +- cmd/fluxctl/root_cmd.go | 2 +- git/errors.go | 2 +- http/client/client.go | 2 +- internal_docs/releasing.md | 2 +- registry/cache/registry.go | 2 +- remote/errors.go | 12 ++++---- site/annotations-tutorial.md | 2 +- site/daemon.md | 2 +- site/faq.md | 2 +- site/fluxctl.md | 10 +++---- site/get-started-developing.md | 14 ++++----- site/helm-operator.md | 4 +-- site/helm-upgrading-to-beta.md | 4 +-- site/monitoring.md | 2 +- site/standalone-setup.md | 2 +- site/troubleshooting.md | 2 +- site/upgrading-to-1.0.md | 8 ++--- test/bin/test-flux | 8 ++--- test/flux-deploy-all.yaml | 2 +- 23 files changed, 73 insertions(+), 73 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 4c699ed6f..92277a149 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,8 +3,8 @@ operator is in [./CHANGELOG-helmop.md](./CHANGELOG-helmop.md). ## 1.10.1 (2019-02-13) -This release provides a deeper integration with Azure (DevOps Git hosts -and ACR) and allows configuring how `fluxctl` finds `fluxd` (useful for +This release provides a deeper integration with Azure (DevOps Git hosts +and ACR) and allows configuring how `fluxctl` finds `fluxd` (useful for clusters with multiple fluxd installations). ### Improvements @@ -19,7 +19,7 @@ clusters with multiple fluxd installations). ### Thanks -Lots of thanks to @alanjcastonguay, @hiddeco, and @sarath-p for their +Lots of thanks to @alanjcastonguay, @hiddeco, and @sarath-p for their contributions to this release. [#1694]: https://github.com/weaveworks/flux/pull/1694 @@ -324,7 +324,7 @@ because it introduces a new flag, `--listen-metrics`. ### Improvements - Prometheus metrics can be exposed on a port different from that of - the flux API, using the flag `--listen-metrics` + the Flux API, using the flag `--listen-metrics` [weaveworks/flux#1325](https://github.com/weaveworks/flux/pull/1325) ### Thanks @@ -555,7 +555,7 @@ reindent blocks the first time it changes a file. ### Improvements -- Let the flux daemon operate without a git repo, and report cluster resources as read-only when there is no corresponding manifest [weaveworks/flux#962](https://github.com/weaveworks/flux/pull/962) +- Let the Flux daemon operate without a git repo, and report cluster resources as read-only when there is no corresponding manifest [weaveworks/flux#962](https://github.com/weaveworks/flux/pull/962) - Reinstate command-line arg for setting the git polling interval `--git-poll-interval` [weaveworks/flux#1030](https://github.com/weaveworks/flux/pull/1030) - Add `--git-ci-skip` (and for more fine control, `--git-ci-skip-message`) for customising flux's commit messages such that CI systems ignore the commits [weaveworks/flux#1011](https://github.com/weaveworks/flux/pull/1011) - Log the daemon version on startup [weaveworks/flux#1017](https://github.com/weaveworks/flux/pull/1017) @@ -661,7 +661,7 @@ registry. - Flux daemon can be configured to populate the git commit author with the name of the requesting user -- When multiple flux daemons share the same configuration repository, +- When multiple Flux daemons share the same configuration repository, each fluxd only sends Slack notifications for commits that affect its branch/path - When a resource is locked the invoking user is recorded, along with @@ -676,7 +676,7 @@ registry. ## 1.0.0 (2017-08-22) -This release introduces significant changes to the way flux works: +This release introduces significant changes to the way Flux works: - The git repository is now the system of record for your cluster state. Flux continually works to synchronise your cluster with the @@ -723,7 +723,7 @@ More informative and helpful UI. - Slack notifications are tidier - Support for releasing to >1 service at a time -- Better behaviour when flux deploys itself +- Better behaviour when Flux deploys itself - More help given for commonly encountered errors - Filter out Kubernetes add-ons from consideration - More consistent Prometheus metric labeling diff --git a/chart/flux/CHANGELOG.md b/chart/flux/CHANGELOG.md index dc712aecb..9766515f4 100644 --- a/chart/flux/CHANGELOG.md +++ b/chart/flux/CHANGELOG.md @@ -39,9 +39,9 @@ ## 0.6.0 (2019-01-14) -**Note** To fix the connectivity problems between Flux and memcached we've changed the -memcached service from headless to ClusterIP. This change will make the Helm upgrade fail -with `ClusterIP field is immutable`. +**Note** To fix the connectivity problems between Flux and memcached we've changed the +memcached service from headless to ClusterIP. This change will make the Helm upgrade fail +with `ClusterIP field is immutable`. Before upgrading to 0.6.0 you have to delete the memcached headless service: @@ -61,16 +61,16 @@ kubectl -n flux delete svc flux-memcached [weaveworks/flux#1626](https://github.com/weaveworks/flux/pull/1626) - Rectify error where `resources` are not `None` by default in `chart/flux/values.yaml` - Add more fields that are actually in `chart/flux/values.yaml` - - Separate `replicaCount` into a flux one and `helmOperator.replicaCount` one + - Separate `replicaCount` into a Flux one and `helmOperator.replicaCount` one - Only create the `flux-helm-tls-ca-config` file if `.Values.helmOperator.tls.caContent` exists. - Useful when doing flux upgrades but do not happen to know or want to specify + Useful when doing Flux upgrades but do not happen to know or want to specify the `caContent` in `values.yaml`. Otherwise, the existing caContent will be overriden with an empty value. [weaveworks/flux#1649](https://github.com/weaveworks/flux/pull/1649) - Add Flux AWS ECR flags [weaveworks/flux#1655](https://github.com/weaveworks/flux/pull/1655) - + ## 0.5.2 (2018-12-20) ### Improvements @@ -123,7 +123,7 @@ Thanks to @davidkarlsen, @stephenmoloney, @batpok, @squaremo, ### Improvements - Updated Helm operator to `v0.4.0` - [weaveworks/flux#1487](https://github.com/weaveworks/flux/pull/1487) + [weaveworks/flux#1487](https://github.com/weaveworks/flux/pull/1487) - Added `--tiller-tls-hostname` Helm operator config flag to the chart [weaveworks/flux#1484](https://github.com/weaveworks/flux/pull/1484) - Include `valueFileSecrets` property in `helm-operator-crd.yaml` diff --git a/chart/flux/README.md b/chart/flux/README.md index b62ff9a31..c310c5a7e 100755 --- a/chart/flux/README.md +++ b/chart/flux/README.md @@ -92,9 +92,9 @@ weaveworks/flux #### To install Flux with a private git host: -When using a private git host, setting the `ssh.known_hosts` variable -is required for enabling successful key matches because `StrictHostKeyChecking` -is enabled during flux git daemon operations. +When using a private git host, setting the `ssh.known_hosts` variable +is required for enabling successful key matches because `StrictHostKeyChecking` +is enabled during Flux git daemon operations. By setting the `ssh.known_hosts` variable, a configmap will be created called `flux-ssh-config` which in turn will be mounted into a volume named @@ -110,7 +110,7 @@ To prevent a potential man-in-the-middle attack, one should verify the ssh keys acquired through the `ssh-keyscan` match expectations using an alternate mechanism. -* Start flux and flux helm operator: +* Start Flux and Flux helm operator: - Using a string for setting `known_hosts` @@ -185,17 +185,17 @@ The following tables lists the configurable parameters of the Weave Flux chart a | ------------------------------- | ------------------------------------------ | ---------------------------------------------------------- | | `image.repository` | Image repository | `quay.io/weaveworks/flux` | `image.tag` | Image tag | `` -| `replicaCount` | Number of flux pods to deploy, more than one is not desirable. | `1` +| `replicaCount` | Number of Flux pods to deploy, more than one is not desirable. | `1` | `image.pullPolicy` | Image pull policy | `IfNotPresent` | `image.pullSecret` | Image pull secret | `None` -| `resources.requests.cpu` | CPU resource requests for the flux deployment | `50m` -| `resources.requests.memory` | Memory resource requests for the flux deployment | `64Mi` -| `resources.limits` | CPU/memory resource limits for the flux deployment | `None` -| `nodeSelector` | Node Selector properties for the flux deployment | `{}` -| `tolerations` | Tolerations properties for the flux deployment | `[]` -| `affinity` | Affinity properties for the flux deployment | `{}` +| `resources.requests.cpu` | CPU resource requests for the Flux deployment | `50m` +| `resources.requests.memory` | Memory resource requests for the Flux deployment | `64Mi` +| `resources.limits` | CPU/memory resource limits for the Flux deployment | `None` +| `nodeSelector` | Node Selector properties for the Flux deployment | `{}` +| `tolerations` | Tolerations properties for the Flux deployment | `[]` +| `affinity` | Affinity properties for the Flux deployment | `{}` | `token` | Weave Cloud service token | `None` -| `extraEnvs` | Extra environment variables for the flux pod(s) | `[]` +| `extraEnvs` | Extra environment variables for the Flux pod(s) | `[]` | `rbac.create` | If `true`, create and use RBAC resources | `true` | `serviceAccount.create` | If `true`, create a new service account | `true` | `serviceAccount.name` | Service account to be used | `flux` @@ -234,7 +234,7 @@ The following tables lists the configurable parameters of the Weave Flux chart a | `memcached.repository` | Image repository | `memcached` | `memcached.resources` | CPU/memory resource requests/limits for memcached | `None` | `helmOperator.create` | If `true`, install the Helm operator | `false` -| `helmOperator.createCRD` | Create the `v1beta1` and `v1alpha2` flux CRDs. Dependent on `helmOperator.create=true` | `true` +| `helmOperator.createCRD` | Create the `v1beta1` and `v1alpha2` Flux CRDs. Dependent on `helmOperator.create=true` | `true` | `helmOperator.repository` | Helm operator image repository | `quay.io/weaveworks/helm-operator` | `helmOperator.tag` | Helm operator image tag | `` | `helmOperator.replicaCount` | Number of helm operator pods to deploy, more than one is not desirable. | `1` @@ -266,8 +266,8 @@ The following tables lists the configurable parameters of the Weave Flux chart a | `helmOperator.nodeSelector` | Node Selector properties for the helmOperator deployment | `{}` | `helmOperator.tolerations` | Tolerations properties for the helmOperator deployment | `[]` | `helmOperator.affinity` | Affinity properties for the helmOperator deployment | `{}` -| `kube.config` | Override for kubectl default config in the flux pod(s). | [See values.yaml](https://github.com/weaveworks/flux/blob/master/chart/flux/values.yaml#L151-L165) -| `prometheus.enabled` | If enbaled, adds prometheus annotations to flux and helmOperator pod(s) | `false` +| `kube.config` | Override for kubectl default config in the Flux pod(s). | [See values.yaml](https://github.com/weaveworks/flux/blob/master/chart/flux/values.yaml#L151-L165) +| `prometheus.enabled` | If enbaled, adds prometheus annotations to Flux and helmOperator pod(s) | `false` Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example: diff --git a/cluster/kubernetes/resource/fluxhelmrelease.go b/cluster/kubernetes/resource/fluxhelmrelease.go index 129bd5f73..2fbd39bbb 100644 --- a/cluster/kubernetes/resource/fluxhelmrelease.go +++ b/cluster/kubernetes/resource/fluxhelmrelease.go @@ -8,7 +8,7 @@ import ( "github.com/weaveworks/flux/resource" ) -// ReleaseContainerName is the name used when flux interprets a +// ReleaseContainerName is the name used when Flux interprets a // FluxHelmRelease as having a container with an image, by virtue of // having a `values` stanza with an image field: // diff --git a/cmd/fluxctl/root_cmd.go b/cmd/fluxctl/root_cmd.go index a0e146557..c2a81f840 100644 --- a/cmd/fluxctl/root_cmd.go +++ b/cmd/fluxctl/root_cmd.go @@ -72,7 +72,7 @@ func (opts *rootOpts) Command() *cobra.Command { cmd.PersistentFlags().StringToStringVar(&opts.Labels, "k8s-fwd-labels", map[string]string{"app": "flux"}, fmt.Sprintf("Labels used to select the fluxd pod a port forward should be created for. You can also set the environment variable %s", envVariableLabels)) cmd.PersistentFlags().StringVarP(&opts.URL, "url", "u", "", - fmt.Sprintf("Base URL of the flux API (defaults to %q if a token is provided); you can also set the environment variable %s", defaultURLGivenToken, envVariableURL)) + fmt.Sprintf("Base URL of the Flux API (defaults to %q if a token is provided); you can also set the environment variable %s", defaultURLGivenToken, envVariableURL)) cmd.PersistentFlags().StringVarP(&opts.Token, "token", "t", "", fmt.Sprintf("Weave Cloud authentication token; you can also set the environment variable %s or %s", envVariableCloudToken, envVariableToken)) diff --git a/git/errors.go b/git/errors.go index f93aa2371..05272fed7 100644 --- a/git/errors.go +++ b/git/errors.go @@ -48,7 +48,7 @@ cross-check with the fingerprint given by func ErrUpstreamNotWritable(url string, actual error) error { help := `Could not write to upstream repository -To keep track of synchronisation, the flux daemon must be able to +To keep track of synchronisation, the Flux daemon must be able to write to the upstream git repository. ` if strings.HasPrefix(url, "http://") || diff --git a/http/client/client.go b/http/client/client.go index 756275265..3fe4d8c1a 100644 --- a/http/client/client.go +++ b/http/client/client.go @@ -178,7 +178,7 @@ func (c *Client) methodWithResp(ctx context.Context, method string, dest interfa return nil } -// get executes a get request against the flux server. it unmarshals the response into dest. +// get executes a get request against the Flux server. it unmarshals the response into dest. func (c *Client) Get(ctx context.Context, dest interface{}, route string, queryParams ...string) error { u, err := transport.MakeURL(c.endpoint, c.router, route, queryParams...) if err != nil { diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md index 1b9a7a69e..0f3a7fb93 100644 --- a/internal_docs/releasing.md +++ b/internal_docs/releasing.md @@ -92,7 +92,7 @@ Get the PR reviewed, and merge it. 6. [Create a release in GitHub](https://github.com/weaveworks/flux/releases/new) -Use a tag name as explained above; semver for the flux daemon, `helm-` +Use a tag name as explained above; semver for the Flux daemon, `helm-` then the semver for the Helm operator. Copy and paste the changelog entry. You may need to remove newlines diff --git a/registry/cache/registry.go b/registry/cache/registry.go index a0323e328..da57f2cf1 100644 --- a/registry/cache/registry.go +++ b/registry/cache/registry.go @@ -19,7 +19,7 @@ var ( It takes time to initially cache all the images. Please wait. -If you have waited for a long time, check the flux logs. Potential +If you have waited for a long time, check the Flux logs. Potential reasons for the error are: no internet, no cache, error with the remote repository. `, diff --git a/remote/errors.go b/remote/errors.go index 760de28d1..584215402 100644 --- a/remote/errors.go +++ b/remote/errors.go @@ -7,7 +7,7 @@ import ( func UnavailableError(err error) error { return &fluxerr.Error{ Type: fluxerr.User, - Help: `Cannot contact flux daemon + Help: `Cannot contact Flux daemon To service this request, we need to ask the agent running in your cluster (fluxd) for some information. But we can't connect to it at @@ -16,7 +16,7 @@ present. This may be because it's not running at all, is temporarily disconnected or has been firewalled. -If you are sure flux is running, you can simply wait a few seconds +If you are sure Flux is running, you can simply wait a few seconds and try the operation again. Otherwise, please consult the installation instructions in our @@ -36,7 +36,7 @@ If you are still stuck, please log an issue: func UpgradeNeededError(err error) error { return &fluxerr.Error{ Type: fluxerr.User, - Help: `Your flux daemon needs to be upgraded + Help: `Your Flux daemon needs to be upgraded ` + err.Error() + ` @@ -44,7 +44,7 @@ To service this request, we need to ask the agent running in your cluster (fluxd) to perform an operation on our behalf, but the version you have running is too old to understand the request. -Please install the latest version of flux and try again. +Please install the latest version of Flux and try again. `, Err: err, @@ -59,7 +59,7 @@ func UnsupportedResourceKind(err error) error { The version of the agent running in your cluster (fluxd) can release updates to the following kinds of pod controller: Deployments, DaemonSets, StatefulSets and CronJobs. When new kinds are added to Kubernetes, we try to support them as -quickly as possible - check here to see if a new version of flux is available: +quickly as possible - check here to see if a new version of Flux is available: https://github.com/weaveworks/flux/releases @@ -74,7 +74,7 @@ that matches your agent. func ClusterError(err error) error { return &fluxerr.Error{ Type: fluxerr.User, - Help: `Error from flux daemon + Help: `Error from Flux daemon The Flux daemon (fluxd) reported this error: diff --git a/site/annotations-tutorial.md b/site/annotations-tutorial.md index b971734cd..c2d29db7d 100644 --- a/site/annotations-tutorial.md +++ b/site/annotations-tutorial.md @@ -83,7 +83,7 @@ make sure you replace `YOURUSER` with your GitHub username in the command below: ```sh -helm upgrade -i flux \ +helm upgrade -i Flux \ --set helmOperator.create=true \ --set helmOperator.createCRD=false \ --set git.url=git@github.com:YOURUSER/flux-get-started \ diff --git a/site/daemon.md b/site/daemon.md index 49bbd490a..c7f7e7244 100644 --- a/site/daemon.md +++ b/site/daemon.md @@ -5,7 +5,7 @@ menu_order: 90 # 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 diff --git a/site/faq.md b/site/faq.md index 34362ff09..25eaf437d 100644 --- a/site/faq.md +++ b/site/faq.md @@ -333,7 +333,7 @@ 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](../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 +then create the configmap, in the same namespace you run Flux in, with something like: kubectl create configmap flux-kubeconfig --from-file=config=./my-kubeconfig diff --git a/site/fluxctl.md b/site/fluxctl.md index 80bf17e69..6c970baf5 100644 --- a/site/fluxctl.md +++ b/site/fluxctl.md @@ -11,7 +11,7 @@ menu_order: 40 - [Connecting fluxctl to the daemon](#connecting-fluxctl-to-the-daemon) * [Flux API service](#flux-api-service) * [Add an SSH deploy key to the repository](#add-an-ssh-deploy-key-to-the-repository) - + [1. Allow flux to generate a key for you](#1-allow-flux-to-generate-a-key-for-you) + + [1. Allow Flux to generate a key for you](#1-allow-flux-to-generate-a-key-for-you) + [2. Specify a key to use](#2-specify-a-key-to-use) - [Controllers](#controllers) * [What is a Controller?](#what-is-a-controller) @@ -115,7 +115,7 @@ fluxctl list-controllers --all-namespaces Flux connects to the repository using an SSH key. You have two options: -### 1. Allow flux to generate a key for you +### 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: @@ -231,7 +231,7 @@ Flags: --k8s-fwd-labels stringToString Labels used to select the fluxd pod a port forward should be created for. You can also set the environment variable FLUX_FORWARD_LABELS (default [app=flux]) --k8s-fwd-ns string Namespace in which fluxd is running, for creating a port forward to access the API. No port forward will be created if a URL or token is given. You can also set the environment variable FLUX_FORWARD_NAMESPACE (default "default") -t, --token string Weave Cloud authentication token; you can also set the environment variable WEAVE_CLOUD_TOKEN or FLUX_SERVICE_TOKEN - -u, --url string Base URL of the flux API (defaults to "https://cloud.weave.works/api/flux" if a token is provided); you can also set the environment variable FLUX_URL + -u, --url string Base URL of the Flux API (defaults to "https://cloud.weave.works/api/flux" if a token is provided); you can also set the environment variable FLUX_URL Use "fluxctl [command] --help" for more information about a command. ``` @@ -455,7 +455,7 @@ quay.io/weaveworks/helloworld:master-9a16ff945b9e Indicates that the `helloworld` image was built against master commit `9a16ff945b9e`. -When automation is turned on flux will, by default, use whatever +When automation is turned on Flux will, by default, use whatever is the latest image on a given repository. If you want to only auto-update your image against a certain subset of tags then you can do that using tag filtering. @@ -525,7 +525,7 @@ or only release images that have a stable semantic version tag (X.Y.Z): fluxctl policy --controller=default:deployment/helloworld --tag-all='semver:*' ``` -Using a semver filter will also affect how flux sorts images, so +Using a semver filter will also affect how Flux sorts images, so that the higher versions will be considered newer. ## Regexp diff --git a/site/get-started-developing.md b/site/get-started-developing.md index f94a88a89..dd3161981 100644 --- a/site/get-started-developing.md +++ b/site/get-started-developing.md @@ -1,6 +1,6 @@ # Get Started Developing Flux -This tutorial is going to walk you through one possible workflow for making a small (actually, tiny) change to flux and building and testing that change locally. +This tutorial is going to walk you through one possible workflow for making a small (actually, tiny) change to Flux and building and testing that change locally. > ### TL;DR > @@ -17,7 +17,7 @@ This tutorial is going to walk you through one possible workflow for making a sm > 1. make a change to the code > 1. see your code changes have been deployed > 1. repeat -> 1. Use `helm` and `skaffold` together to deploy changes to the flux helm chart. +> 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 @@ -64,7 +64,7 @@ Now that we know everything is working with `flux-getting-started`, we're going 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`: + 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`: ``` NAME READY STATUS RESTARTS AGE @@ -77,7 +77,7 @@ Now that we know everything is working with `flux-getting-started`, we're going 1. Clone `git@github.com:/flux.git` replacing `` with your GitHub username. - In the same terminal you ran `eval $(minikube docker-env)`, run `dep ensure` 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: + In the same terminal you ran `eval $(minikube docker-env)`, run `dep ensure` 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: ``` Successfully built 606610e0f4ef Successfully tagged quay.io/weaveworks/flux:latest @@ -118,7 +118,7 @@ Now that we know everything is working with `flux-getting-started`, we're going secret/flux-git-deploy configured ``` - Congrats you just deployed your local flux to your default namespace. Check that everything is running: + Congrats you just deployed your local Flux to your default namespace. Check that everything is running: ```sh kubectl get pods --selector=name=flux @@ -132,7 +132,7 @@ Now that we know everything is working with `flux-getting-started`, we're going 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: +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 ``` @@ -178,4 +178,4 @@ Now that we know everything is working with `flux-getting-started`, we're going ## 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! \ No newline at end of file +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! \ No newline at end of file diff --git a/site/helm-operator.md b/site/helm-operator.md index 2dcb93311..ef09aaa0c 100644 --- a/site/helm-operator.md +++ b/site/helm-operator.md @@ -166,7 +166,7 @@ helm --tls --tls-verify \ ls ``` -### deploy weave flux helm-operator +### deploy weave Flux helm-operator First create a new Kubernetes TLS secret for the client certs; @@ -225,7 +225,7 @@ metadata: ## Installing Weave Flux helm-operator for Weave Cloud -In order to use the Helm operator with Weave Cloud you have to apply the `HelmRelease` CRD definition and the operator +In order to use the Helm operator with Weave Cloud you have to apply the `HelmRelease` CRD definition and the operator deployment in the `weave` namespace: ```bash diff --git a/site/helm-upgrading-to-beta.md b/site/helm-upgrading-to-beta.md index 36d81f991..2d55e2582 100644 --- a/site/helm-upgrading-to-beta.md +++ b/site/helm-upgrading-to-beta.md @@ -25,7 +25,7 @@ Here are some things to know: The safest way to upgrade is to avoid deletions and fights by stopping the old operator. Replacing it with the new one (e.g., by changing the -deployment, or re-releasing the flux chart with the new version) will +deployment, or re-releasing the Flux chart with the new version) will have that effect. Once the old operator is not running, it is safe to deploy the new @@ -35,7 +35,7 @@ since the new operator will ignore them. ## Upgrading the operator deployment -### Using the flux chart +### Using the Flux chart The chart (from v0.5.0, or from this git repo) provides the correct arguments to the operator; to upgrade, do diff --git a/site/monitoring.md b/site/monitoring.md index 9c38f52b9..9d0e39ac4 100644 --- a/site/monitoring.md +++ b/site/monitoring.md @@ -3,7 +3,7 @@ title: Monitoring Weave Flux menu_order: 70 --- -The flux daemon exposes `/metrics` endpoints which can be scraped for +The Flux daemon exposes `/metrics` endpoints which can be scraped for monitoring data in Prometheus format; exact metric names and help are available from the endpoints themselves. diff --git a/site/standalone-setup.md b/site/standalone-setup.md index 0c74b4671..fd35470d3 100644 --- a/site/standalone-setup.md +++ b/site/standalone-setup.md @@ -107,7 +107,7 @@ by removing the deploy key. 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. +`~/.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 diff --git a/site/troubleshooting.md b/site/troubleshooting.md index c6b777e63..3fbf4a8cf 100644 --- a/site/troubleshooting.md +++ b/site/troubleshooting.md @@ -31,7 +31,7 @@ This is also documented in the ### `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/weaveworks/flux/issues/new)! ### Flux answers everything with `git repo is not configured` diff --git a/site/upgrading-to-1.0.md b/site/upgrading-to-1.0.md index b16dd21ba..20f8d34dd 100644 --- a/site/upgrading-to-1.0.md +++ b/site/upgrading-to-1.0.md @@ -80,7 +80,7 @@ git (and GitHub) workflows to manage your cluster. In summary, you will need to: 1. Remove the old Flux resources from your cluster - 2. Delete any deployment keys + 2. Delete any deployment keys 3. Run the new Flux resources 4. Install a new deploy key @@ -151,7 +151,7 @@ key used by Flux with > other words, it tries to keep the cluster running whatever is > represented in the repo. (Though it doesn’t delete things, yet.) -To run the new Flux with Weave Cloud: +To run the new Flux with Weave Cloud: * Go to your instance settings (the cog icon) and click the “Config” then “Deploy” menu items @@ -185,8 +185,8 @@ Before making any changes, get the config so that it can be consulted later: > *Important! If you have Flux resources committed to git* > > The first thing to do here is to remove any manifests for running -> flux you have stored in git, before deleting them in the cluster -> (below). If you don’t remove these, running the new flux daemon will +> Flux you have stored in git, before deleting them in the cluster +> (below). If you don’t remove these, running the new Flux daemon will > restore the old configuration. You can delete the Flux resources by referring to the manifest files diff --git a/test/bin/test-flux b/test/bin/test-flux index d606c3f96..857a0d93b 100755 --- a/test/bin/test-flux +++ b/test/bin/test-flux @@ -21,14 +21,14 @@ minikube delete --profile "$PROFILE" || true minikube start --profile "$PROFILE" --keep-context MINIKUBE_IP=$(minikube --profile "$PROFILE" ip) -# Copy the latest flux image into the minikube VM +# Copy the latest Flux image into the minikube VM docker save quay.io/weaveworks/flux:latest | (eval $(minikube --profile "$PROFILE" docker-env) && docker load) # Create a central git repo inside the minikube VM and get the host key for ssh access minikube --profile "$PROFILE" ssh -- git init --bare /home/docker/flux.git ssh-keyscan $MINIKUBE_IP > "$KNOWN_HOSTS" -# Deploy flux in kube-system namespace, supplying it with the SSH keys it needs to access & authenticate the config repo +# Deploy Flux in kube-system namespace, supplying it with the SSH keys it needs to access & authenticate the config repo kubectl --context "$PROFILE" -n kube-system create secret generic flux-git-deploy --from-file=identity="$SSH_PRIVATE_KEY" kubectl --context "$PROFILE" -n kube-system create configmap ssh-known-hosts --from-file=known_hosts="$KNOWN_HOSTS" sed -e "s/MINIKUBE_IP/$MINIKUBE_IP/" "$BASEDIR/flux-deploy-all.yaml" | kubectl --context "$PROFILE" -n kube-system apply -f- @@ -113,7 +113,7 @@ git -C "$CONFIG_REPO" push -u origin master # Wait two minutes for flux-sync tag to point to local HEAD wait_for_sync 120 -# Examine services via flux API an assert container versions are correct +# Examine services via Flux API an assert container versions are correct assert_controller_container default default:deployment/helloworld helloworld quay.io/weaveworks/helloworld:master-a000001 assert_controller_container default default:deployment/helloworld sidecar quay.io/weaveworks/sidecar:master-a000001 @@ -123,7 +123,7 @@ fluxctl --url http://$(minikube -p flux-test ip):30080/api/flux automate --contr # Wait two minutes for two (automation and release) commits to appear wait_for_upstream_commits 120 2 -# Examine services via flux API an assert container versions are updated +# Examine services via Flux API an assert container versions are updated assert_controller_container default default:deployment/helloworld helloworld quay.io/weaveworks/helloworld:master-9a16ff945b9e assert_controller_container default default:deployment/helloworld sidecar quay.io/weaveworks/sidecar:master-a000002 diff --git a/test/flux-deploy-all.yaml b/test/flux-deploy-all.yaml index 7fbee480f..672f8c66d 100644 --- a/test/flux-deploy-all.yaml +++ b/test/flux-deploy-all.yaml @@ -36,7 +36,7 @@ spec: selector: name: memcached --- -# Expose flux to fluxctl +# Expose Flux to fluxctl apiVersion: v1 kind: Service metadata: From 056e1d4ef74f8b2fdf7bbd8f2c1a1faa31d0d01f Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Fri, 1 Mar 2019 13:47:46 -0500 Subject: [PATCH 09/12] fixes bullet indentation to align with contents --- internal_docs/releasing.md | 52 +++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md index 0f3a7fb93..78ace9d21 100644 --- a/internal_docs/releasing.md +++ b/internal_docs/releasing.md @@ -39,92 +39,92 @@ which will create the tag. 1. If the release is a new minor version, create a "release series" branch and push it to GitHub. -Depending on what is to be includeed in the release, you may need to + Depending on what is to be includeed in the release, you may need to pick a point from which branch that is not HEAD of master. But usually, it will be HEAD of master. 2. From the release series branch, create _another_ branch for the particular release. This will be what you submit as a PR. -For example, + For example, -```sh -git checkout release/1.8.x -git pull origin -git checkout -b release/1.8.1 -``` + ```sh + git checkout release/1.8.x + git pull origin + git checkout -b release/1.8.1 + ``` 3. Put the commits you want in the release, into your branch -If you just created a new release series branch, i.e., this is a + If you just created a new release series branch, i.e., this is a `x.y.0` patch release, you may already have what you need, because you've just branched from master. -If this is _not_ the first release on this branch, you will need to + If this is _not_ the first release on this branch, you will need to either merge master, or cherry-pick commits from master, to get the things you want in the release. 4. Put an entry into the changelog -For the Flux daemon, it's `CHANGELOG.md`; for the Helm operator, it's + For the Flux daemon, it's `CHANGELOG.md`; for the Helm operator, it's `CHANGELOG-helmop.md`. Follow the format established, and commit your change. -If you cherry-picked commits, remember to only mention those changes. + If you cherry-picked commits, remember to only mention those changes. -To compile a list of people (GitHub usernames) to thank, you can use a + To compile a list of people (GitHub usernames) to thank, you can use a script (if you have access to weaveworks/dx) or peruse the commits/PRs merged/issues since the last release. There's no exact way to do it. Be generous. 5. Post the branch as a PR to the release series -Push the patch release branch -- e.g., `release/1.8.1` -- to GitHub, + Push the patch release branch -- e.g., `release/1.8.1` -- to GitHub, and create a PR from it. -**Please note** You will need to change the branch the PR targets, + > **Note:** You will need to change the branch the PR targets, from `master` to the release series, e.g., `release/1.8.x`, while creating the PR. -Get the PR reviewed, and merge it. +6. Get the PR reviewed, and merge it. **Creating the release** -6. [Create a release in GitHub](https://github.com/weaveworks/flux/releases/new) +7. [Create a release in GitHub](https://github.com/weaveworks/flux/releases/new) -Use a tag name as explained above; semver for the Flux daemon, `helm-` + Use a tag name as explained above; semver for the Flux daemon, `helm-` then the semver for the Helm operator. -Copy and paste the changelog entry. You may need to remove newlines + Copy and paste the changelog entry. You may need to remove newlines that have been inserted by your editor, so that it wraps nicely. -Publishing the release will create the tag, and that will trigger CI + Publishing the release will create the tag, and that will trigger CI to build images and binaries. **After publishing the release** -7. Put an entry in the checkpoint database +8. Put an entry in the checkpoint database -Add a row to the [checkpoint + Add a row to the [checkpoint database](https://checkpoint-api.weave.works/admin) (or ask someone at Weaveworks to do so). This is so that the up-to-date check will report the latest available version correctly. -8. Merge the release series branch back into master, so it has the +9. Merge the release series branch back into master, so it has the changelog entry. -You can do this by creating a new PR in GitHub -- you don't need to + You can do this by creating a new PR in GitHub -- you don't need to create any new branches, since you want to merge a branch that already exists. -9. Consider updating the deploy manifest examples and the Helm +10. Consider updating the deploy manifest examples and the Helm chart. -The example manifests are in [deploy](./deploy/) and + The example manifests are in [deploy](./deploy/) and [deploy-helm](./deploy-helm/). Check the changes included in the release, to see if arguments, volume mounts, etc., have changed. -You can do these as additional PRs. Read on, for how to publish a new + You can do these as additional PRs. Read on, for how to publish a new Helm chart version. ## Helm chart release process From 561e42179b8b913cf4c58e01a42011cbca9e9573 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Fri, 1 Mar 2019 13:52:13 -0500 Subject: [PATCH 10/12] corrects line breaking among many many other reasons since this is a markdown file and to reasonably view a raw markdown file you must use word wrapping, I hope the awkwardness of the previous commit well demonstrates why this change greatly simplifies the document. --- internal_docs/releasing.md | 85 +++++++++++--------------------------- 1 file changed, 23 insertions(+), 62 deletions(-) diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md index 78ace9d21..bef27381d 100644 --- a/internal_docs/releasing.md +++ b/internal_docs/releasing.md @@ -5,46 +5,31 @@ The release process needs to do these things: - create a new release on GitHub, with a tag - push Docker image(s) to quay.io - possibly upload the [`fluxctl` binaries](/site/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 + - make sure the version is entered into the checkpoint database so that up-to-date checks report back accurate information Much of this is automated, but it needs a human to turn the wheel. ## Overview -The Flux daemon and the Helm operator have separate releases, and use -different branches and tags. Flux daemon releases use just a semver -version, like `1.8.1`, and the Helm operator uses the prefix "helm", -e.g., `helm-0.5.0`. +The Flux daemon and the Helm operator have separate releases, and use different branches and tags. Flux daemon releases use just a semver version, like `1.8.1`, and the Helm operator uses the prefix "helm", e.g., `helm-0.5.0`. -Each minor version has its own "release series" branch, from which -patch releases will be put together, called e.g., `release/1.8.x`, or -for the Helm operator, `release/helm-0.5.x`. +Each minor version has its own "release series" branch, from which patch releases will be put together, called e.g., `release/1.8.x`, or for the Helm operator, `release/helm-0.5.x`. -The CircleCI script runs builds for tags, which push Docker images and -upload binaries. This is triggered by creating a release in GitHub, -which will create the tag. +The CircleCI script runs builds for tags, which push Docker images and upload binaries. This is triggered by creating a release in GitHub, which will create the tag. ## Requirements -- CircleCI must have a secret environmental variable called - `GITHUB_TOKEN` which is a personal access token. (This is almost - certainly already set up, but mentioned here in case it needs to be - reinstated.) +- CircleCI must have a secret environmental variable called `GITHUB_TOKEN` which is a personal access token. (This is almost certainly already set up, but mentioned here in case it needs to be reinstated.) ## Release process **Preparing the release PR** -1. If the release is a new minor version, create a "release series" - branch and push it to GitHub. +1. If the release is a new minor version, create a "release series" branch and push it to GitHub. - Depending on what is to be includeed in the release, you may need to -pick a point from which branch that is not HEAD of master. But -usually, it will be HEAD of master. + Depending on what is to be includeed in the release, you may need to pick a point from which branch that is not HEAD of master. But usually, it will be HEAD of master. -2. From the release series branch, create _another_ branch for the - particular release. This will be what you submit as a PR. +2. From the release series branch, create _another_ branch for the particular release. This will be what you submit as a PR. For example, @@ -56,35 +41,24 @@ usually, it will be HEAD of master. 3. Put the commits you want in the release, into your branch - If you just created a new release series branch, i.e., this is a -`x.y.0` patch release, you may already have what you need, because -you've just branched from master. + If you just created a new release series branch, i.e., this is a `x.y.0` patch release, you may already have what you need, because you've just branched from master. - If this is _not_ the first release on this branch, you will need to -either merge master, or cherry-pick commits from master, to get the -things you want in the release. + If this is _not_ the first release on this branch, you will need to either merge master, or cherry-pick commits from master, to get the things you want in the release. 4. Put an entry into the changelog - For the Flux daemon, it's `CHANGELOG.md`; for the Helm operator, it's -`CHANGELOG-helmop.md`. Follow the format established, and commit your + For the Flux daemon, it's `CHANGELOG.md`; for the Helm operator, it's `CHANGELOG-helmop.md`. Follow the format established, and commit your change. If you cherry-picked commits, remember to only mention those changes. - To compile a list of people (GitHub usernames) to thank, you can use a -script (if you have access to weaveworks/dx) or peruse the commits/PRs -merged/issues since the last release. There's no exact way to do -it. Be generous. + To compile a list of people (GitHub usernames) to thank, you can use a script (if you have access to weaveworks/dx) or peruse the commits/PRs merged/issues since the last release. There's no exact way to do it. Be generous. 5. Post the branch as a PR to the release series - Push the patch release branch -- e.g., `release/1.8.1` -- to GitHub, -and create a PR from it. + Push the patch release branch -- e.g., `release/1.8.1` -- to GitHub, and create a PR from it. - > **Note:** You will need to change the branch the PR targets, -from `master` to the release series, e.g., `release/1.8.x`, while -creating the PR. + > **Note:** You will need to change the branch the PR targets, from `master` to the release series, e.g., `release/1.8.x`, while creating the PR. 6. Get the PR reviewed, and merge it. @@ -92,40 +66,27 @@ creating the PR. 7. [Create a release in GitHub](https://github.com/weaveworks/flux/releases/new) - Use a tag name as explained above; semver for the Flux daemon, `helm-` -then the semver for the Helm operator. + Use a tag name as explained above; semver for the Flux daemon, `helm-` then the semver for the Helm operator. - Copy and paste the changelog entry. You may need to remove newlines -that have been inserted by your editor, so that it wraps nicely. + Copy and paste the changelog entry. You may need to remove newlines that have been inserted by your editor, so that it wraps nicely. - Publishing the release will create the tag, and that will trigger CI -to build images and binaries. + Publishing the release will create the tag, and that will trigger CI to build images and binaries. **After publishing the release** 8. Put an entry in the checkpoint database - Add a row to the [checkpoint -database](https://checkpoint-api.weave.works/admin) (or ask someone at -Weaveworks to do so). This is so that the up-to-date check will report -the latest available version correctly. + Add a row to the [checkpoint database](https://checkpoint-api.weave.works/admin) (or ask someone at Weaveworks to do so). This is so that the up-to-date check will report the latest available version correctly. -9. Merge the release series branch back into master, so it has the - changelog entry. +9. Merge the release series branch back into master, so it has the changelog entry. - You can do this by creating a new PR in GitHub -- you don't need to -create any new branches, since you want to merge a branch that already -exists. + You can do this by creating a new PR in GitHub -- you don't need to create any new branches, since you want to merge a branch that already exists. -10. Consider updating the deploy manifest examples and the Helm - chart. +10. Consider updating the deploy manifest examples and the Helm chart. - The example manifests are in [deploy](./deploy/) and -[deploy-helm](./deploy-helm/). Check the changes included in the -release, to see if arguments, volume mounts, etc., have changed. + The example manifests are in [deploy](./deploy/) and [deploy-helm](./deploy-helm/). Check the changes included in the release, to see if arguments, volume mounts, etc., have changed. - You can do these as additional PRs. Read on, for how to publish a new -Helm chart version. + You can do these as additional PRs. Read on, for how to publish a new Helm chart version. ## Helm chart release process From 6b55fe194b3e5c1c579dff5d2de54dd18e00f126 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Fri, 1 Mar 2019 13:52:34 -0500 Subject: [PATCH 11/12] corrects mispelling --- internal_docs/releasing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/internal_docs/releasing.md b/internal_docs/releasing.md index bef27381d..2749e1e01 100644 --- a/internal_docs/releasing.md +++ b/internal_docs/releasing.md @@ -27,7 +27,7 @@ The CircleCI script runs builds for tags, which push Docker images and upload bi 1. If the release is a new minor version, create a "release series" branch and push it to GitHub. - Depending on what is to be includeed in the release, you may need to pick a point from which branch that is not HEAD of master. But usually, it will be HEAD of master. + Depending on what is to be included in the release, you may need to pick a point from which branch that is not HEAD of master. But usually, it will be HEAD of master. 2. From the release series branch, create _another_ branch for the particular release. This will be what you submit as a PR. From dd9a25b442594775a285c1f580e25e5434874579 Mon Sep 17 00:00:00 2001 From: Dimitri Mitropoulos Date: Fri, 1 Mar 2019 14:14:41 -0500 Subject: [PATCH 12/12] fixes linting on markdown tables MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Don't worry, I'm a certified vim ninja - many of these changes were like 4 keystrokes. (⌐■_■) --- chart/flux/README.md | 174 +++++++++++++++++++------------------- site/daemon.md | 98 ++++++++++----------- site/fluxctl.md | 10 +-- site/garbagecollection.md | 12 +-- site/helm-operator.md | 40 ++++----- site/monitoring.md | 20 ++--- 6 files changed, 177 insertions(+), 177 deletions(-) diff --git a/chart/flux/README.md b/chart/flux/README.md index c310c5a7e..50fdf8db9 100755 --- a/chart/flux/README.md +++ b/chart/flux/README.md @@ -181,93 +181,93 @@ You should also remove the deploy key from your GitHub repository. The following tables lists the configurable parameters of the Weave Flux chart and their default values. -| Parameter | Description | Default | -| ------------------------------- | ------------------------------------------ | ---------------------------------------------------------- | -| `image.repository` | Image repository | `quay.io/weaveworks/flux` -| `image.tag` | Image tag | `` -| `replicaCount` | Number of Flux pods to deploy, more than one is not desirable. | `1` -| `image.pullPolicy` | Image pull policy | `IfNotPresent` -| `image.pullSecret` | Image pull secret | `None` -| `resources.requests.cpu` | CPU resource requests for the Flux deployment | `50m` -| `resources.requests.memory` | Memory resource requests for the Flux deployment | `64Mi` -| `resources.limits` | CPU/memory resource limits for the Flux deployment | `None` -| `nodeSelector` | Node Selector properties for the Flux deployment | `{}` -| `tolerations` | Tolerations properties for the Flux deployment | `[]` -| `affinity` | Affinity properties for the Flux deployment | `{}` -| `token` | Weave Cloud service token | `None` -| `extraEnvs` | Extra environment variables for the Flux pod(s) | `[]` -| `rbac.create` | If `true`, create and use RBAC resources | `true` -| `serviceAccount.create` | If `true`, create a new service account | `true` -| `serviceAccount.name` | Service account to be used | `flux` -| `service.type` | Service type to be used (exposing the Flux API outside of the cluster is not advised) | `ClusterIP` -| `service.port` | Service port to be used | `3030` -| `git.url` | URL of git repo with Kubernetes manifests | `None` -| `git.branch` | Branch of git repo to use for Kubernetes manifests | `master` -| `git.path` | Path within git repo to locate Kubernetes manifests (relative path) | `None` -| `git.user` | Username to use as git committer | `Weave Flux` -| `git.email` | Email to use as git committer | `support@weave.works` -| `git.setAuthor` | If set, the author of git commits will reflect the user who initiated the commit and will differ from the git committer. | `false` -| `git.label` | Label to keep track of sync progress, used to tag the Git branch | `flux-sync` -| `git.ciSkip` | Append "[ci skip]" to commit messages so that CI will skip builds | `false` -| `git.pollInterval` | Period at which to poll git repo for new commits | `5m` -| `git.timeout` | Duration after which git operations time out | `20s` -| `git.secretName` | Kubernetes secret with the SSH private key. Superceded by `helmOperator.git.secretName` if set. | `None` -| `ssh.known_hosts` | The contents of an SSH `known_hosts` file, if you need to supply host key(s) | `None` -| `registry.pollInterval` | Period at which to check for updated images | `5m` -| `registry.rps` | Maximum registry requests per second per host | `200` -| `registry.burst` | Maximum number of warmer connections to remote and memcache | `125` -| `registry.trace` | Output trace of image registry requests to log | `false` -| `registry.insecureHosts` | Use HTTP rather than HTTPS for the image registry domains | `None` -| `registry.cacheExpiry` | Duration to keep cached image info (deprecated) | `None` -| `registry.excludeImage` | Do not scan images that match these glob expressions; if empty, 'k8s.gcr.io/*' images are excluded | `None` -| `registry.ecr.region` | Restrict ECR scanning to these AWS regions; if empty, only the cluster's region will be scanned | `None` -| `registry.ecr.includeId` | Restrict ECR scanning to these AWS account IDs; if empty, all account IDs that aren't excluded may be scanned | `None` -| `registry.ecr.excludeId` | Do not scan ECR for images in these AWS account IDs; the default is to exclude the EKS system account | `602401143452` -| `registry.acr.enabled` | Mount `azure.json` via HostPath into the Flux Pod, enabling Flux to use AKS's service principal for ACR authentication | `false` -| `registry.acr.hostPath` | Alternative location of `azure.json` on the host | `/etc/kubernetes/azure.json` -| `registry.dockercfg.enabled` | Mount `config.json` via Secret into the Flux Pod, enabling Flux to use a custom docker config file | `false` -| `registry.dockercfg.secretName` | Kubernetes secret with the docker config.json | `None` -| `memcached.verbose` | Enable request logging in memcached | `false` -| `memcached.maxItemSize` | Maximum size for one item | `5m` -| `memcached.maxMemory` | Maximum memory to use, in megabytes | `128` -| `memcached.pullSecret` | Image pull secret | `None` -| `memcached.repository` | Image repository | `memcached` -| `memcached.resources` | CPU/memory resource requests/limits for memcached | `None` -| `helmOperator.create` | If `true`, install the Helm operator | `false` -| `helmOperator.createCRD` | Create the `v1beta1` and `v1alpha2` Flux CRDs. Dependent on `helmOperator.create=true` | `true` -| `helmOperator.repository` | Helm operator image repository | `quay.io/weaveworks/helm-operator` -| `helmOperator.tag` | Helm operator image tag | `` -| `helmOperator.replicaCount` | Number of helm operator pods to deploy, more than one is not desirable. | `1` -| `helmOperator.pullPolicy` | Helm operator image pull policy | `IfNotPresent` -| `helmOperator.pullSecret` | Image pull secret | `None` -| `helmOperator.updateChartDeps` | Update dependencies for charts | `true` -| `helmOperator.git.pollInterval` | Period at which to poll git repo for new commits | `git.pollInterval` -| `helmOperator.git.timeout` | Duration after which git operations time out | `git.timeout` -| `helmOperator.git.secretName` | The name of the kubernetes secret with the SSH private key, supercedes `git.secretName` | `None` -| `helmOperator.chartsSyncInterval` | Interval at which to check for changed charts | `3m` -| `helmOperator.extraEnvs` | Extra environment variables for the Helm operator pod | `[]` -| `helmOperator.logReleaseDiffs` | Helm operator should log the diff when a chart release diverges (possibly insecure) | `false` -| `helmOperator.allowNamespace` | If set, this limits the scope to a single namespace. If not specified, all namespaces will be watched | `None` -| `helmOperator.tillerNamespace` | Namespace in which the Tiller server can be found | `kube-system` -| `helmOperator.tls.enable` | Enable TLS for communicating with Tiller | `false` -| `helmOperator.tls.verify` | Verify the Tiller certificate, also enables TLS when set to true | `false` -| `helmOperator.tls.secretName` | Name of the secret containing the TLS client certificates for communicating with Tiller | `helm-client-certs` -| `helmOperator.tls.keyFile` | Name of the key file within the k8s secret | `tls.key` -| `helmOperator.tls.certFile` | Name of the certificate file within the k8s secret | `tls.crt` -| `helmOperator.tls.caContent` | Certificate Authority content used to validate the Tiller server certificate | `None` -| `helmOperator.tls.hostname` | The server name used to verify the hostname on the returned certificates from the Tiller server | `None` -| `helmOperator.configureRepositories.enable` | Enable volume mount for a `repositories.yaml` configuration file and respository cache | `false` -| `helmOperator.configureRepositories.volumeName` | Name of the volume for the `repositories.yaml` file | `repositories-yaml` -| `helmOperator.configureRepositories.secretName` | Name of the secret containing the contents of the `repositories.yaml` file | `flux-helm-repositories` -| `helmOperator.configureRepositories.cacheName` | Name for the repository cache volume | `repositories-cache` -| `helmOperator.resources.requests.cpu` | CPU resource requests for the helmOperator deployment | `50m` -| `helmOperator.resources.requests.memory` | Memory resource requests for the helmOperator deployment | `64Mi` -| `helmOperator.resources.limits` | CPU/memory resource limits for the helmOperator deployment | `None` -| `helmOperator.nodeSelector` | Node Selector properties for the helmOperator deployment | `{}` -| `helmOperator.tolerations` | Tolerations properties for the helmOperator deployment | `[]` -| `helmOperator.affinity` | Affinity properties for the helmOperator deployment | `{}` -| `kube.config` | Override for kubectl default config in the Flux pod(s). | [See values.yaml](https://github.com/weaveworks/flux/blob/master/chart/flux/values.yaml#L151-L165) -| `prometheus.enabled` | If enbaled, adds prometheus annotations to Flux and helmOperator pod(s) | `false` +| Parameter | Default | Description +| ----------------------------------------------- | ---------------------------------------------------- | --- +| `image.repository` | `quay.io/weaveworks/flux` | Image repository +| `image.tag` | `` | Image tag +| `replicaCount` | `1` | Number of Flux pods to deploy, more than one is not desirable. +| `image.pullPolicy` | `IfNotPresent` | Image pull policy +| `image.pullSecret` | `None` | Image pull secret +| `resources.requests.cpu` | `50m` | CPU resource requests for the Flux deployment +| `resources.requests.memory` | `64Mi` | Memory resource requests for the Flux deployment +| `resources.limits` | `None` | CPU/memory resource limits for the Flux deployment +| `nodeSelector` | `{}` | Node Selector properties for the Flux deployment +| `tolerations` | `[]` | Tolerations properties for the Flux deployment +| `affinity` | `{}` | Affinity properties for the Flux deployment +| `token` | `None` | Weave Cloud service token +| `extraEnvs` | `[]` | Extra environment variables for the Flux pod(s) +| `rbac.create` | `true` | If `true`, create and use RBAC resources +| `serviceAccount.create` | `true` | If `true`, create a new service account +| `serviceAccount.name` | `flux` | Service account to be used +| `service.type` | `ClusterIP` | Service type to be used (exposing the Flux API outside of the cluster is not advised) +| `service.port` | `3030` | Service port to be used +| `git.url` | `None` | URL of git repo with Kubernetes manifests +| `git.branch` | `master` | Branch of git repo to use for Kubernetes manifests +| `git.path` | `None` | Path within git repo to locate Kubernetes manifests (relative path) +| `git.user` | `Weave Flux` | Username to use as git committer +| `git.email` | `support@weave.works` | Email to use as git committer +| `git.setAuthor` | `false` | If set, the author of git commits will reflect the user who initiated the commit and will differ from the git committer. +| `git.label` | `flux-sync` | Label to keep track of sync progress, used to tag the Git branch +| `git.ciSkip` | `false` | Append "[ci skip]" to commit messages so that CI will skip builds +| `git.pollInterval` | `5m` | Period at which to poll git repo for new commits +| `git.timeout` | `20s` | Duration after which git operations time out +| `git.secretName` | `None` | Kubernetes secret with the SSH private key. Superceded by `helmOperator.git.secretName` if set. +| `ssh.known_hosts` | `None` | The contents of an SSH `known_hosts` file, if you need to supply host key(s) +| `registry.pollInterval` | `5m` | Period at which to check for updated images +| `registry.rps` | `200` | Maximum registry requests per second per host +| `registry.burst` | `125` | Maximum number of warmer connections to remote and memcache +| `registry.trace` | `false` | Output trace of image registry requests to log +| `registry.insecureHosts` | `None` | Use HTTP rather than HTTPS for the image registry domains +| `registry.cacheExpiry` | `None` | Duration to keep cached image info (deprecated) +| `registry.excludeImage` | `None` | Do not scan images that match these glob expressions; if empty, 'k8s.gcr.io/*' images are excluded +| `registry.ecr.region` | `None` | Restrict ECR scanning to these AWS regions; if empty, only the cluster's region will be scanned +| `registry.ecr.includeId` | `None` | Restrict ECR scanning to these AWS account IDs; if empty, all account IDs that aren't excluded may be scanned +| `registry.ecr.excludeId` | `602401143452` | Do not scan ECR for images in these AWS account IDs; the default is to exclude the EKS system account +| `registry.acr.enabled` | `false` | Mount `azure.json` via HostPath into the Flux Pod, enabling Flux to use AKS's service principal for ACR authentication +| `registry.acr.hostPath` | `/etc/kubernetes/azure.json` | Alternative location of `azure.json` on the host +| `registry.dockercfg.enabled` | `false` | Mount `config.json` via Secret into the Flux Pod, enabling Flux to use a custom docker config file +| `registry.dockercfg.secretName` | `None` | Kubernetes secret with the docker config.json +| `memcached.verbose` | `false` | Enable request logging in memcached +| `memcached.maxItemSize` | `5m` | Maximum size for one item +| `memcached.maxMemory` | `128` | Maximum memory to use, in megabytes +| `memcached.pullSecret` | `None` | Image pull secret +| `memcached.repository` | `memcached` | Image repository +| `memcached.resources` | `None` | CPU/memory resource requests/limits for memcached +| `helmOperator.create` | `false` | If `true`, install the Helm operator +| `helmOperator.createCRD` | `true` | Create the `v1beta1` and `v1alpha2` Flux CRDs. Dependent on `helmOperator.create=true` +| `helmOperator.repository` | `quay.io/weaveworks/helm-operator` | Helm operator image repository +| `helmOperator.tag` | `` | Helm operator image tag +| `helmOperator.replicaCount` | `1` | Number of helm operator pods to deploy, more than one is not desirable. +| `helmOperator.pullPolicy` | `IfNotPresent` | Helm operator image pull policy +| `helmOperator.pullSecret` | `None` | Image pull secret +| `helmOperator.updateChartDeps` | `true` | Update dependencies for charts +| `helmOperator.git.pollInterval` | `git.pollInterval` | Period at which to poll git repo for new commits +| `helmOperator.git.timeout` | `git.timeout` | Duration after which git operations time out +| `helmOperator.git.secretName` | `None` | The name of the kubernetes secret with the SSH private key, supercedes `git.secretName` +| `helmOperator.chartsSyncInterval` | `3m` | Interval at which to check for changed charts +| `helmOperator.extraEnvs` | `[]` | Extra environment variables for the Helm operator pod +| `helmOperator.logReleaseDiffs` | `false` | Helm operator should log the diff when a chart release diverges (possibly insecure) +| `helmOperator.allowNamespace` | `None` | If set, this limits the scope to a single namespace. If not specified, all namespaces will be watched +| `helmOperator.tillerNamespace` | `kube-system` | Namespace in which the Tiller server can be found +| `helmOperator.tls.enable` | `false` | Enable TLS for communicating with Tiller +| `helmOperator.tls.verify` | `false` | Verify the Tiller certificate, also enables TLS when set to true +| `helmOperator.tls.secretName` | `helm-client-certs` | Name of the secret containing the TLS client certificates for communicating with Tiller +| `helmOperator.tls.keyFile` | `tls.key` | Name of the key file within the k8s secret +| `helmOperator.tls.certFile` | `tls.crt` | Name of the certificate file within the k8s secret +| `helmOperator.tls.caContent` | `None` | Certificate Authority content used to validate the Tiller server certificate +| `helmOperator.tls.hostname` | `None` | The server name used to verify the hostname on the returned certificates from the Tiller server +| `helmOperator.configureRepositories.enable` | `false` | Enable volume mount for a `repositories.yaml` configuration file and respository cache +| `helmOperator.configureRepositories.volumeName` | `repositories-yaml` | Name of the volume for the `repositories.yaml` file +| `helmOperator.configureRepositories.secretName` | `flux-helm-repositories` | Name of the secret containing the contents of the `repositories.yaml` file +| `helmOperator.configureRepositories.cacheName` | `repositories-cache` | Name for the repository cache volume +| `helmOperator.resources.requests.cpu` | `50m` | CPU resource requests for the helmOperator deployment +| `helmOperator.resources.requests.memory` | `64Mi` | Memory resource requests for the helmOperator deployment +| `helmOperator.resources.limits` | `None` | CPU/memory resource limits for the helmOperator deployment +| `helmOperator.nodeSelector` | `{}` | Node Selector properties for the helmOperator deployment +| `helmOperator.tolerations` | `[]` | Tolerations properties for the helmOperator deployment +| `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) Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example: diff --git a/site/daemon.md b/site/daemon.md index c7f7e7244..0c775e65a 100644 --- a/site/daemon.md +++ b/site/daemon.md @@ -42,52 +42,52 @@ document. fluxd requires setup and offers customization though a multitude of flags. -|flag | default | purpose | -|------------------------|-------------------------------|---------| -|--listen -l | `:3030` | listen address where /metrics and API will be served| -|--listen-metrics | | listen address for /metrics endpoint | -|--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-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`) | -|--git-path | | path within git repo to locate Kubernetes manifests (relative path)| -|--git-user | `Weave Flux` | username to use as git committer| -|--git-email | `support@weave.works` | email to use as git committer| -|--git-set-author | false | if set, the author of git commits will reflect the user who initiated the commit and will differ from the git committer| -|--git-label | | label to keep track of sync progress; overrides both --git-sync-tag and --git-notes-ref| -|--git-sync-tag | `flux-sync` | tag to use to mark sync progress for this cluster (old config, still used if --git-label is not supplied)| -|--git-notes-ref | `flux` | ref to use for keeping commit annotations in git notes| -|--git-poll-interval | `5m` | period at which to fetch any new commits from the git repo | -|--git-timeout | `20s` | duration after which git operations time out | -|**syncing** | | control over how config is applied to the cluster | -|--sync-interval | `5m` | apply the git config to the cluster at least this often. New commits may provoke more frequent syncs | -|--sync-garbage-collection | `false` | experimental: when set, fluxd will delete resources that it created, but are no longer present in git (see [garbage collection](./garbagecollection.md)) | -|**registry cache** | | (none of these need overriding, usually) | -|--memcached-hostname | `memcached` | hostname for memcached service to use for caching image metadata| -|--memcached-timeout | `1s` | maximum time to wait before giving up on memcached requests| -|--memcached-service | `memcached` | SRV service used to discover memcache servers| -|--registry-cache-expiry | `1h` | Duration to keep cached registry tag info. Must be < 1 month.| -|--registry-poll-interval| `5m` | period at which to poll registry for new images| -|--registry-rps | `200` | maximum registry requests per second per host| -|--registry-burst | `125` | maximum number of warmer connections to remote and memcache| -|--registry-insecure-host| [] | registry hosts to use HTTP for (instead of HTTPS) | -|--registry-exclude-image| `["k8s.gcr.io/*"]` | do not scan images that match these glob expressions | -|--docker-config | `""` | path to a Docker config file with default image registry credentials | -|--registry-ecr-region | `[]` | Allow these AWS regions when scanning images from ECR (multiple values allowed); defaults to the detected cluster region | -|--registry-ecr-include-id | `[]` | Include these AWS account ID(s) when scanning images in ECR (multiple values allowed); empty means allow all, unless excluded | -|--registry-ecr-exclude-id | `[]` | Exclude these AWS account ID(s) when scanning ECR (multiple values allowed); defaults to the EKS system account, so system images will not be scanned | -|**k8s-secret backed ssh keyring configuration** | | | -|--k8s-secret-name | `flux-git-deploy` | name of the k8s secret used to store the private SSH key| -|--k8s-secret-volume-mount-path | `/etc/fluxd/ssh` | mount location of the k8s secret storing the private SSH key| -|--k8s-secret-data-key | `identity` | data key holding the private SSH key within the k8s secret| -|**k8s configuration** | | | | -|--k8s-namespace-whitelist| | Experimental, optional: restrict the view of the cluster to the namespaces listed. All namespaces are included if this is not set.| -|**upstream service** | | | | -|--connect | | connect to an upstream service e.g., Weave Cloud, at this base address| -|--token | | authentication token for upstream service| -|**SSH key generation** | | | -|--ssh-keygen-bits | | -b argument to ssh-keygen (default unspecified)| -|--ssh-keygen-type | | -t argument to ssh-keygen (default unspecified)| +| Flag | Default | Purpose +| ------------------------------------------------ | ------------------------ | --- +| --listen -l | `:3030` | listen address where /metrics and API will be served +| --listen-metrics | | listen address for /metrics endpoint +| --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-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`) +| --git-path | | path within git repo to locate Kubernetes manifests (relative path) +| --git-user | `Weave Flux` | username to use as git committer +| --git-email | `support@weave.works` | email to use as git committer +| --git-set-author | false | if set, the author of git commits will reflect the user who initiated the commit and will differ from the git committer +| --git-label | | label to keep track of sync progress; overrides both --git-sync-tag and --git-notes-ref +| --git-sync-tag | `flux-sync` | tag to use to mark sync progress for this cluster (old config, still used if --git-label is not supplied) +| --git-notes-ref | `flux` | ref to use for keeping commit annotations in git notes +| --git-poll-interval | `5m` | period at which to fetch any new commits from the git repo +| --git-timeout | `20s` | duration after which git operations time out +| **syncing:** control over how config is applied to the cluster +| --sync-interval | `5m` | apply the git config to the cluster at least this often. New commits may provoke more frequent syncs +| --sync-garbage-collection | `false` | experimental: when set, fluxd will delete resources that it created, but are no longer present in git (see [garbage collection](./garbagecollection.md)) +| **registry cache:** (none of these need overriding, usually) +| --memcached-hostname | `memcached` | hostname for memcached service to use for caching image metadata +| --memcached-timeout | `1s` | maximum time to wait before giving up on memcached requests +| --memcached-service | `memcached` | SRV service used to discover memcache servers +| --registry-cache-expiry | `1h` | Duration to keep cached registry tag info. Must be < 1 month. +| --registry-poll-interval | `5m` | period at which to poll registry for new images +| --registry-rps | `200` | maximum registry requests per second per host +| --registry-burst | `125` | maximum number of warmer connections to remote and memcache +| --registry-insecure-host | [] | registry hosts to use HTTP for (instead of HTTPS) +| --registry-exclude-image | `["k8s.gcr.io/*"]` | do not scan images that match these glob expressions +| --docker-config | `""` | path to a Docker config file with default image registry credentials +| --registry-ecr-region | `[]` | Allow these AWS regions when scanning images from ECR (multiple values allowed); defaults to the detected cluster region +| --registry-ecr-include-id | `[]` | Include these AWS account ID(s) when scanning images in ECR (multiple values allowed); empty means allow all, unless excluded +| --registry-ecr-exclude-id | `[]` | Exclude these AWS account ID(s) when scanning ECR (multiple values allowed); defaults to the EKS system account, so system images will not be scanned +| **k8s-secret backed ssh keyring configuration** +| --k8s-secret-name | `flux-git-deploy` | name of the k8s secret used to store the private SSH key +| --k8s-secret-volume-mount-path | `/etc/fluxd/ssh` | mount location of the k8s secret storing the private SSH key +| --k8s-secret-data-key | `identity` | data key holding the private SSH key within the k8s secret +| **k8s configuration** +| --k8s-namespace-whitelist | | Experimental, optional: restrict the view of the cluster to the namespaces listed. All namespaces are included if this is not set. +| **upstream service** +| --connect | | connect to an upstream service e.g., Weave Cloud, at this base address +| --token | | authentication token for upstream service +| **SSH key generation** +| --ssh-keygen-bits | | -b argument to ssh-keygen (default unspecified) +| --ssh-keygen-type | | -t argument to ssh-keygen (default unspecified) diff --git a/site/fluxctl.md b/site/fluxctl.md index 6c970baf5..27106cbbc 100644 --- a/site/fluxctl.md +++ b/site/fluxctl.md @@ -433,11 +433,11 @@ Issuing a deployment change results in a version control change/git commit, keeping the history of the actions. The Flux daemon can be started with several flags that impact the commit information: -| flag | purpose | default | -|-------------------|-------------------------------|------------| -| git-user | committer name | Weave Flux | -| git-email | committer name | support@weave.works | -| git-set-author | override the commit author | false | +| flag | purpose | default +| -------------- | -------------------------- | --- +| git-user | committer name | `Weave Flux` +| git-email | committer email | `support@weave.works` +| git-set-author | override the commit author | false Actions triggered by a user through the Weave Cloud UI or the CLI `fluxctl` tool, can have the commit author information customized. This is handy for providing extra context in the diff --git a/site/garbagecollection.md b/site/garbagecollection.md index d7de28cda..5870bcdc0 100644 --- a/site/garbagecollection.md +++ b/site/garbagecollection.md @@ -13,7 +13,7 @@ When garbage collection is enabled, syncing is done in two phases: 1. Apply all the manifests in the git repo (as delimited by the branch and path arguments), and give each resource a label marking it as having been synced from this source. - + 2. Ask the cluster for all the resources marked as being from this source, and delete those that were not applied in step 1. @@ -38,8 +38,8 @@ branch, and paths), there is a possiblility that resources no longer present in the new source will be missed (i.e., not deleted) by garbage collection, and you will need to delete them by hand. -| Config change | What happens | -|-------------------|--------------| -| git URL or branch | If the manifests at the new git repo are the same, they will all be relabelled, and things will proceed as usual. If they are different, the resources from the old repo will be missed by garbage collection and will need to be deleted by hand | -| path added | Existing resources will be relabelled, and new resources (from manifests in the new path) will be created. Then things will proceed as usual. | -| path removed | The resources from manifests in the removed path will be missed by garbage collection, and will need to be deleted by hand. Other resources will be treated as usual. | +| Config change | What happens +| ----------------- | --- +| git URL or branch | If the manifests at the new git repo are the same, they will all be relabelled, and things will proceed as usual. If they are different, the resources from the old repo will be missed by garbage collection and will need to be deleted by hand +| path added | Existing resources will be relabelled, and new resources (from manifests in the new path) will be created. Then things will proceed as usual. +| path removed | The resources from manifests in the removed path will be missed by garbage collection, and will need to be deleted by hand. Other resources will be treated as usual. diff --git a/site/helm-operator.md b/site/helm-operator.md index ef09aaa0c..e7570dd9c 100644 --- a/site/helm-operator.md +++ b/site/helm-operator.md @@ -8,26 +8,26 @@ Events and acts accordingly, installing, upgrading or deleting a Chart release. 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. | -|--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. | +| 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. +| --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 Weave Flux helm-operator and Helm with TLS enabled diff --git a/site/monitoring.md b/site/monitoring.md index 9d0e39ac4..cfd2ccdfa 100644 --- a/site/monitoring.md +++ b/site/monitoring.md @@ -11,13 +11,13 @@ available from the endpoints themselves. The following metrics are exposed: -| metric | description | -|---------------------------------------|-----------------------------------------| -| `flux_cache_request_duration_seconds` | Duration of cache requests, in seconds. | -| `flux_client_fetch_duration_seconds` | Duration of remote image metadata requests | -| `flux_daemon_job_duration_seconds` | Duration of job execution, in seconds | -| `flux_daemon_queue_duration_seconds` | Duration of time spent in the job queue before execution | -| `flux_daemon_queue_length_count` | Count of jobs waiting in the queue to be run | -| `flux_daemon_sync_duration_seconds` | Duration of git-to-cluster synchronisation | -| `flux_registry_fetch_duration_seconds` | Duration of image metadata requests (from cache) | -| `flux_fluxd_connection_duration_seconds` | Duration in seconds of the current connection to fluxsvc | +| metric | description +| ---------------------------------------- | --- +| `flux_cache_request_duration_seconds` | Duration of cache requests, in seconds. +| `flux_client_fetch_duration_seconds` | Duration of remote image metadata requests +| `flux_daemon_job_duration_seconds` | Duration of job execution, in seconds +| `flux_daemon_queue_duration_seconds` | Duration of time spent in the job queue before execution +| `flux_daemon_queue_length_count` | Count of jobs waiting in the queue to be run +| `flux_daemon_sync_duration_seconds` | Duration of git-to-cluster synchronisation +| `flux_registry_fetch_duration_seconds` | Duration of image metadata requests (from cache) +| `flux_fluxd_connection_duration_seconds` | Duration in seconds of the current connection to fluxsvc