wait for bootstrap node to be up before launching other nodes #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We replace the bootstrap service with a headless service and have
all nodes connect directly to the pod ips.
This exposes a bug where nodes are stuck with zero connections if
they try to connect too early. This was previously masked by kubeproxy.
We fix that by adding an init container which waits for the first
bootstrap node to accept connections.
The bootstrap attribute is now declarative: we no longer consider
every baking node as bootstrap. The bootstrap: true must be passed
in values.yaml
We add headless services in order to give the pods a meaningful FQDN.
Rename "bootstrap" statefulset to "baker" to reflect this new model.
Other changes:
do not hardcode the protocol version in the key-importer script,
pass it as a variable instead
In values.yaml, baker nodes and regular nodes are now listed
separately, which simplifies the code in other places.
invited values always has one node even though the main topology
may have several. To add more nodes to an invite, edit the yaml
manually. fix Invite yaml should only contain a single peer node oxheadalpha/tezos-k8s#69