Jhack enters the political arena with a boom and yet another devastating, controversial developer tool: jhack elect
.
This command is only available from jhack
0.4.3.3
If you are writing an integration test, or working with your development cloud and Juju has somewhat decided that myapp/7
should be the leader of your deployment, but you really, really disagree and want myapp/2
to be in charge instead, worry no longer! You now wield the power of advanced hackery and election manipulation: type
jhack elect myapp/2
ā¦and in no time (about a minute, to be precise), myapp/7
shall be deposed and myapp/2
elected in its place.
But how?
Run
jhack elect myapp/2 --dry-run
ā¦and see for yourself (some details might be hidden in the code though).
TLDR: Jhack is killing the container agents on all units except the one you want to elect, waiting for reelection to occur, then restarting everything up. Itās also patching the pebble plans on those units to inject a tiny python server that happily replies āoh Iām so healthy!ā to any pebble/kubernetes probe that comes along, so nobody will realize that the agent is down.
Troubleshooting
Stopped units come back to life before reelection has occurred
The solution to this might be to add logic to keep watching the units and keep them dead until reelection occurs. Come talk to me if you witness this, Iāve seen it happen but have been unable to reproduce.
Units receive stop
and start
events
First of all, donāt worry too much: the pod/container should not be churning. Jhack is tricking both pebble and kubernetes to think that everything is fine with the unit. However, we still have to find a way to trick the Juju controller. Know how to do that? Get in touch!
Fact is, you can safely ignore those events as they are in fact spurious. Your unit isnāt really being restarted. Telling the charm to ignore those events though can be tricky: consider using a partial jhack lobotomy
for that!