I think what you really want is to define a preInstall step which does
the following:
- 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.
Best
Alex
On 22/09/2016 17:52, Sam Corbett wrote:
Hi all,
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
express this.
At the moment I have:
services:
- id: leader
type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
brooklyn.config:
preInstallCommand: |
test -f ~/.ssh/id_rsa.pub || (mkdir -p ~/.ssh ; ssh-keygen -t
rsa -b 4096 -f ~/.ssh/id_rsa -N '')
brooklyn.initializers:
- type: org.apache.brooklyn.core.sensor.ssh.SshCommandSensor
brooklyn.config:
name: ssh.publicKey
command: cat ~/.ssh/id_rsa.pub 2>/dev/null
period: 1m
- id: group
type: org.apache.brooklyn.entity.group.DynamicCluster
brooklyn.config:
initialSize: 1
memberSpec:
$brooklyn:entitySpec:
type:
org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
brooklyn.config:
# Allow SSH from leader.
preInstallCommand:
$brooklyn:formatString:
- "mkdir -p ~/.ssh && echo '%s' >> ~/.ssh/authorized_keys"
-
$brooklyn:component("leader").attributeWhenReady("ssh.publicKey")
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.
Sam
