Hi Richard-
I've found the problem: you're not specifying a type for
`consul.serverReference`. If a parameter is defined without any type,
it defaults to a string (at BasicSpecParameter.inferType), causing a
coercion exception when it tries to `config().get` the key. The
coercion problem
Thanks Duncan. That bit of the blueprint is working well - the server
cluster is able to come up normally, the first member being the bootstrap
server, and subsequent members able to detect the first and automatically
join the cluster, through the chained attributeWhenReady calls that you
noticed.
Richard,
I haven't quite got my head round what you're doing but I did notice that
you were chaining attributeWhenReady calls
https://github.com/rdowner/brooklyn-consul/blob/master/catalog/consul/consul-server-cluster.bom#L50
which
I don't think you can do as attributeWhenReady returns a
BrooklynD
Thanks Alex. Your blueprint is similar to mine, although consul.server in
my case is taken from the cluster.first.entity sensor of a DynamicCluster.
I've uploaded my code to https://github.com/rdowner/brooklyn-consul - can
you spot anything odd there?
Thanks
Richard.
On 17 July 2017 at 10:58, Ale
Hi Richard-
What you're doing looks fine. Maybe something is wrong with the
"consul.serverReference" value, or there is a bug around special
treatment of parameters. The blueprint below shows what I think you're
doing, several ways, and all work, both in bash and in the config view
(IE ful
Hello all.
I have a catalog item for an entity type. This has a number of parameters,
including one parameter which is intended to hold a reference to an entity.
This works fine; I can see in the "config" pane of the entity this:
consul.serverReference Consul Server (bootstrap)
What I want to do