charm-k8s-mattermost

~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost:readiness-probe

  1. Git
  2. lp:~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost
  3. readiness-probe
Last commit made on 2020-06-07
Get this branch:
git clone -b readiness-probe https://git.launchpad.net/~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost
Only Paul Collins can upload to this branch. If you are Paul Collins please log in for upload directions.

Branch merges

Branch information

Name:
readiness-probe
Repository:
lp:~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost

Recent commits

b4dcc32... by Paul Collins

add readiness probe

87681ab... by Paul Collins

include application name in cluster name for blue/green deployments

04b68a4... by Paul Collins

add clustering setting

39f8350... by Paul Collins

ensure we don't add duplicate secrets and volumeConfigs

02705f1... by Paul Collins

clearer status w/r/t pod maintenance

9eeb757... by Paul Collins

ensure secret names and keys are the same

c7e0f6f... by Paul Collins

add licence setting, create and mount secret, point mattermost at it

9150c79... by Paul Collins

copy and mutate the pod spec when adding k8s resources

d937be6... by Paul Collins

update to pod spec version 3 for secret-backed volume support

fbaa672... by Paul Collins

replace leadership settings with controller-backed charm state

Using leadership settings doesn't work very well as units
are coming and going, since the db relation is between units.

What can and does happen is that as unit 0 is going away, it
holds leadership and zaps the settings while processing its
relation departed hooks. Unit 1 is coming up, and processing
its own relation joined hooks, but since it does not hold
leadership, it cannot store db_uri, etc. anywhere and when
it finally does become the leader, it sees that the settings
are empty and assumes that the DB relation has not been made.