Sharing objects between entities through rebinds

[Sam Corbett]

Hi all,

I have an object I'd like to share between several entities.

Object o = new Object()
e1.setConfig(C, o)
e2.setConfig(C, o)
e1.getConfig(C) == e2.getConfig(C)

But after rebinding to the application,

e1.getConfig(C) != e2.getConfig(C)

Brooklyn/the rebinder has reconstructed two distinct instances of the
object.

Should I use a different pattern? Should I never use this pattern? In
this case I don't think it's _too_ much of a problem because I can set
the config on the application and call `getApplication().getConfig(C)`.

It's definitely worth calling this out in the documentation.

Cheers,

Sam

[Alex Heneveld]

Good question Sam. Configuration objects are normally meant to be
static data hence the behaviour you are seeing. We do need to call this
out. Could you update the docs to make this clear?

There have been occasions when it is used to share dynamic information
but in general this is an anti-pattern and we should be very careful
with that ... really we should find a better way. In a pinch accessing
the application's config object will work for now, but this also will
fail if an application is distributed across multiple management nodes.

Sensors and effectors are the primary way to share and modify state.
Although there are times when other patterns are wanted and there are a
few I've used though I'm not sure they are ideal so worth a conversation
here on the list.

Sam, what's your use case?

Best
Alex

[Sam Corbett]

I have a single entity and a cluster of entities that are configured to
install a number of files of application-specific data for a single day.
All the entities must always use the same day's data.

I'm working on allowing the reconfiguration of entities to use a
different day's data. At the moment this entails uploading the new data
to each server and then restarting them all. Newly created entities
(e.g. from a cluster resize) must be started with the new day's data.

My thought was to configure the entity specs with a shared object that
has a notion of the 'active' date and keeps a reference of the data used
for other dates. When entities are started they ask the object what data
they should install. Obviously the pattern fails if the entities do not
use the same object.

My alternative is to set the active date and data as a
BasicAttributeSensorAndConfigKey on the entity specs, and to update the
cluster's member spec when switching to a new day. I shied away from
this as I was unsure of the correctness of updating config on
already-deployed entities.

Any comments?

Sam

[Alex Heneveld]

Sam,

I'd be inclined to have a BasicAttributeSensorAndConfigKey DAY_FOR_DATA
and an effector to updateDayForData.
* At the cluster level the effector would set the config, emit the
sensor, and call the effector on all suitable children.
* At the node level the effector would set the config, emit the sensor,
and run through the installation and update.

By setting the config, new nodes will get the latest data by
inheritance. The sensor isn't needed ... include it only if desired.

We currently have a warning about changing config after entity
creation. I think we could remove this as it does make sense to change
config with proviso it only affects subsequent actions normally -- but
make this clear in the docs. I like the mechanism used for policies
where changing config is linked to a method -- longer term we could look
at sharing that with entity config.

Best
Alex