I think what you really want is to define a preInstall step which does
- run the bash and output the key
- publish a sensor from the output of the bash
(Instead of the polling sensor.)
I'm working on something which should let you do that nicely.
Another thing which you could do is to set extraSshPublicKeyData as a
provisioning property on the follower taking the attribute-when-ready.
But that might block provisioning until it is up so probably better as
you've done it.
Final idea I'll toss out is to define leader and follower as base types
then set up a cluster with firstMemberSpec: leader.
On 22/09/2016 17:52, Sam Corbett wrote:
I'm writing a blueprint in which a "leader" entity must be able to SSH
to a group of followers. I'm canvassing for opinions on a clean way to
At the moment I have:
- id: leader
test -f ~/.ssh/id_rsa.pub || (mkdir -p ~/.ssh ; ssh-keygen -t
rsa -b 4096 -f ~/.ssh/id_rsa -N '')
- type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor
command: cat ~/.ssh/id_rsa.pub 2>/dev/null
- id: group
# Allow SSH from leader.
- "mkdir -p ~/.ssh && echo '%s' >> ~/.ssh/authorized_keys"
This is more or less satisfactory but I don't like the repeated
polling for id_rsa.pub. Is there a case for a sensor that stops
executing once some condition is met? In the case above it would
either be a zero exit code or a non-empty stdout.