Comment 5 for bug 1849323

Revision history for this message
Rodrigo Barbieri (rodrigo-barbieri2010) wrote :

Hi Ed,

I think you got some understanding backwards, if I understood your comment #3 correctly. When you said "vault/1 is presenting the same settings that were previously set by vault/2" I can see in your pastebin that is not the case.

Line 28, before power off and vault/2 is leader: ceph-osd/0_token: '"s.9aSiyapUKfFHbpBqzaNGfYd0"'
Line 50, after power off and vault/1 is leader: ceph-osd/0_token: '"s.dWjKyjxR3JXzr67qpKCC6EOm"'

I'm not sure if you have re-run the command in line 38 (the sqlite command), but you should have seen a different token there upon re-running that command.

vault/0 didn't present any tokens because currently the vault charm does not propagate the tokens to other vault units. Also, the leadership change from vault/2 to vault/1 does not hit the bug, as vault/1 < vault/2, therefore the charms will pick up the change. There are no timestamps in your pastebin, but in comment #4 when you said "barbican-vault charm used the same token twice successfully" it makes sense, as the tokens were refreshed on leader changed and read by barbican-vault units successfully as per the vault/2 => vault/1 transition.

If the change was the opposite, from vault/1 to vault/2, the charms would still be trying to use the token provided by vault/1 despite vault/2 being the leader and providing new tokens.