The pattern:
create, write, close, rename
is *not* robust in many circumstances. The data blocks from the write
are not always flushed/persisted before the rename (metadata) changes
meaning you can end up where the replacement file is corrupted
(usually has 0 bytes at the end).
Change-Id: Icdd2bb6f20330e5e94b3081f0d0b8a74417f60d4
This removes an echo from the haproxy anchor, and renders
the related IDENTIFIER variable value directly inline instead.
The echo approach fails under some condition related to host
reboots, resulting in faulty input data for the script and
bad output haproxy configs, with e.g. "frontend -fe".
Change-Id: Id4e258b04290a8ce96b8b518a9c541ecedeee39e
This adds "set -u" (in addition to the existing -x) to the anchor
scripts. This should fix an issue seen occasionally in the haproxy
chart which is only explainable by the IDENTIFIER variable failing
to get set correctly.
All variables used in the anchor scripts ought to be defined, and
there's no need to rely on blank strings as defaults.
"set -e" was considered for this, but may have unintended side-effects:
-u should be safe and avoid the issue we've seen.
Change-Id: Idbc2f9f77d4754874999d5d83d322a17076c7392
- Add validation in the anchor that backend IP addresses
and ports sourced from Kubernetes are valid looking strings.
Change-Id: I7539b633dc49efd7262a22c6f9ff040880d9724f
- Some reported cases that the haproxy config was corrupted during
node reboots. Attempt to add additional safeguards of coordination
between the anchor and the service pod.
- Support nulling out a default entry in the service list
- Add additional log statements in the anchor
Change-Id: Ie673c50e1037d5dff2b9f67b14032e188183a5d9
To be able to run with the nobody user, an init container
is used in the haproxy-anchor pod to change the ownership and
permissions of '/host/etc/promenade/haproxy'. Security conext
was included in 'etc/kubernetes/manifests/haproxy.yaml' and
'promenade/schemas/Genesis.yaml' schema was updated to included
run_as_user property for haproxy pod.
Change-Id: Id248face0be43c417284ceb781997634a9c4dd5e
- When the anchor provides a new haproxy config file
to the running haproxy, add a reasonable check that
the new config is valid:
- Is it a valid config file per haproxy
- Does it contain the expected number of frontends
- Update helm version for linting to 2.14.1
Change-Id: I7a49deb372831c44f05c7baa870735c515519cb2
* added in missing recursive flag to the chmod command used to remove
extraneous permissions from CURATED_DIRS
* added commands to change permissions for manifests and configurations
that are copied to the host
Change-Id: I174db09061c3162db11dd976a55132f5fad7a80d
Continuation of Ia1449d188c15b71dd756e96b1ea2d4a672011a17.
This patch creates the additional var "conf.anchor.enable_cleanup"
that is true by default. False value will effectively
disable cleanup procedure.
Change-Id: I7f74454190dcd1d563d6cb3c9fef8504a3e0806a
There was a bug related to missing haproxy config files:
/etc/promenade/haproxy/haproxy.cfg
/etc/kubernetes/manifests/haproxy.yaml
Those files are initially generated with static pods and
after that it periodically updated by haproxy-anchor.
Most plausible reason why it could be missed is haproxy-anchor cleaned
it up while terminating. To solve the issue there were restored manually.
This patch tries to make such a situation clearer by two things:
1) it leaves a message in a cleanup file that haproxy-anchor was
terminated and the cleaup happened.
2) instead of removing files it moves them to backup dir from that
they could be restored easily.
Change-Id: Ia1449d188c15b71dd756e96b1ea2d4a672011a17
This removes the reliance on coredns for APIserver discovery, allowing
a simpler configuration that is compatible with corednx 1.0.x
Change-Id: Ia3b7b5627c16ec47af6b0d6d5e8dee2674e9b1ee
Chris Wedgwood