Hello all: As part of SeaClouds project, we are planning to add support to Brooklyn to be able to migrate entities from one location to another. In this moment we are in a design phase, guessing which is the best approach to integrate our further work with Brooklyn in the smoothest way possible, in order to make the community to use our work even without SeaClouds Platform.
As I’m quite sure that migration is something that probably will be already you’re considering it, I would love to share my ideas before starting to code it, ir order to avoid wasting resources and time. Currently I have found two different ways: 1. Control the migration process from an upper level with an virtual entity (like SameServerEntity) which holds the logic. This entity wraps the original entity (which has to support migration, tagged by for example an interface Migrable otherwise a runtime exception will be thrown). This could simplify the migration process, as you have all the control of the process from a omniscient father. 2. Each entity is responsible of his own migration (they exposes the ability to migrate with the presence of a sensor for example), so it communicates with the father and the siblings to propagate the message that a migration is in progress, in order to let them to refresh their config keys or restart the application (if the entity doesn’t support live refresh). This requires to handle an asynchronous conversation between multiple entities, and it could be tricky to implement the refresh properties method for every kind of entity. In both approaches I think that the creation of new effectors it’s a must, so we can define two interfaces: * RefresheableConfiguration: It represents that the entity can reload his config keys on the fly by triggering the effector ReloadProperties, which notifies the entity to do what is needed to make the software to realize that some config key or env variable changed) * Migrable: It defines that the entity can be cloned to another location by triggering the defector CloneTo which takes a location. After this modifications are done, the behavior of Brooklyn during the migration process will depend on the approach we take. For example for the basic web chat application (LoadBalancer + Webservers connected with a single Database), i thought about two sequence diagrams: What do you think? PS: Sorry for the length but I think it’s really important to have some feedback before continuing with my work. Best, Adrian.
