DevFW-CICD/ingress-nginx-helm
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Auto stash before merge of "master" and "master/master"

Browse source
This commit is contained in:
Manuel de Brito Fontes 2017-10-20 22:38:27 -03:00
parent 004ddbcd2f
commit 6537ff3ebf
7 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/development.md
View file

@ -64,7 +64,7 @@ Build a raw server binary
$ make build
```
[TODO](https://github.com/kubernetes/ingress/issues/387): add more specific instructions needed for raw server binary.
[TODO](https://github.com/kubernetes/ingress-nginx/issues/387): add more specific instructions needed for raw server binary.
Build a local container image

2
docs/examples/customization/custom-configuration/README.md
View file

@ -16,7 +16,7 @@ metadata:
```
```
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/customization/cutom-configuration/configmap.yaml \
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/examples/customization/custom-configuration/configmap.yaml \
| kubectl apply -f -
```

2
docs/examples/customization/custom-errors/README.md
View file

@ -1,4 +1,4 @@
This example shows how is possible to use a custom backend to render custom error pages. The code of this example is located here [custom-error-pages](https://github.com/kubernetes/ingress/tree/master/examples/customization/custom-errors/nginx)
This example shows how is possible to use a custom backend to render custom error pages. The code of this example is located here [custom-error-pages](https://github.com/kubernetes/ingress-nginx/tree/master/docs/examples/customization/custom-errors)
The idea is to use the headers `X-Code` and `X-Format` that NGINX pass to the backend in case of an error to find out the best existent representation of the response to be returned. i.e. if the request contains an `Accept` header of type `json` the error should be in that format and not in `html` (the default in NGINX).

4
docs/examples/customization/custom-headers/README.md
View file

@ -5,10 +5,10 @@ use a ConfigMap to configure a custom list of headers to be passed to the upstre
server
```console
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/customization/custom-headers/configmap.yaml \
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/examples/customization/custom-headers/configmap.yaml \
| kubectl apply -f -
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/customization/custom-headers/custom-headers.yaml \
curl https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/docs/examples/customization/custom-headers/custom-headers.yaml \
| kubectl apply -f -
```

2
docs/user-guide/annotations.md
View file

@ -264,7 +264,7 @@ By default NGINX uses `http` to reach the services. Adding the annotation `ingre
### Service Upstream
By default the NGINX ingress controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration. This annotation disables that behavior and instead uses a single upstream in NGINX, the service's Cluster IP and port. This can be desirable for things like zero-downtime deployments as it reduces the need to reload NGINX configuration when Pods come up and down. See issue [#257](https://github.com/kubernetes/ingress/issues/257).
By default the NGINX ingress controller uses a list of all endpoints (Pod IP/port) in the NGINX upstream configuration. This annotation disables that behavior and instead uses a single upstream in NGINX, the service's Cluster IP and port. This can be desirable for things like zero-downtime deployments as it reduces the need to reload NGINX configuration when Pods come up and down. See issue [#257](https://github.com/kubernetes/ingress-nginx/issues/257).
#### Known Issues