Sequencer entity

[grkvlt]

An entity and a group that manage sequential sensor values

[aledsage]

I can guess at why these are useful (e.g. some clusters require us to give each member an id that are sequential numbers). However, it would be very useful if you could give us some concrete use-cases so that we understand why these are being added to Brooklyn.

If that is the use-case, I'd prefer the effector approach, with DSL support to invoke the effector and format the result. That feels more explicit compared to the SequenceGroup. But it really depends what use-cases you're envisaging.

[aledsage]

super-class will have instantiated app - don't do it here, and delete the private field app. Also delete tearDown as that is done by super.

[aledsage]

Can we be sure that e1, e2, e3` will be the order of the members? Is that because it is called sequentially with the order that the entities were created?

[aledsage]

I'd prefer we follow the naming conventions of AtomicInteger - so rename increment to incrementAndGet, and delete nextValue + nextString.

I'm inclined to let the caller do the formatting of the result, rather than having separate nextValue and nextString. The difference between those two methods, and their interaction, feels as though it might confuse.

[grkvlt]

Good idea, that would make things more obvious and simpler.

[aledsage]

@grkvlt (cc @drigodwin) given we have DynamicCluster.CLUSTER_MEMBER_ID, where do we need this sequencer entity as opposed to just using that?

[grkvlt]

@aledsage the use case in mind was to sequentially number across multiple clusters (i.e a fabric spread around several locations) which needed the implicit, SequenceGroup-based mechanism. However the explicit (effector based) SequenceEntity version also seemed useful, so I left it in.

[grkvlt]

@drigodwin we need to document this, I will add some descriptive text explaining this for Brooklyn docs

[ahgittin]

I feel like this will soon be superseded, by being able to point at some shared-scoped atomic integer and request a getAndIncrement directly in YAML as part of start. Haven't looked in detail but if that impl could be done as an extension of DynamicGroup could the code here be simplified?

That said not that opposed to adding for now if useful with an expectation it might fall away.

[grkvlt]

@mikezaccardo is this still useful, e.g. for HLF blueprints?

[mikezaccardo]

@grkvlt this would indeed be useful for the Hyperledger Fabric multi-cluster in place of this entity: https://github.com/cloudsoft/brooklyn-hyperledger/blob/c85c215d725017b787c133c1483a21f4e9433b09/catalog/hyperledger/multi-cluster.bom#L205-L251

[drigodwin]

I think this is useful as @mikezaccardo has highlighted so I'm going to merge this now.