-
Notifications
You must be signed in to change notification settings - Fork 11
Description
Consider the reusable recipe available here. It allows to run a Cassandra cluster from Roboconf.
What is important is...
imports: cassandraNode.* (optional);
Now, let's assume one wants to deploy two Cassandra clusters within the same Roboconf application. Channels would be a solution, but we have not yet implemented them (see #14). Another solution that was introduced for specialization was sub-typing. Which is fine for exports. And for imports. As long as you do not make the graph portion something reusable.
Currently, if we write something like...
cassandraForJames {
extends: cassandraNode;
}
cassandraForSomethingElse {
extends: cassandraNode;
}
... no matter what we do, cassandraForJames will be notified every time a cassandraForSomethingElse appears or disappears. And vice-versa. They will see each other because they inherit the...
imports: cassandraNode.* (optional);
... statement.
While we would like the behavior to be « import my exact siblings ». This is why we should introduce the self import statement in our graph. Thus, we would update our reusable recipe for Cassandra with...
imports: SELF.* (optional);
... and cassandraForJames would only see cassandraForJames instances, and cassandraForSomethingElse would only see cassandraForSomethingElse instances. SELF would become a specific key word. That would improve reusable recipes. 😎