Overriding domain level configurations at the server-group level
brian.stansberry Jul 15, 2010 1:05 PMOur domain model design is currently heavy on defining things at the domain level (to allow reuse) and then mapping those things onto ServerGroups.
But, what happens when the user wants to change something but only have it affect 1 server group, and not another?
One possibility is to make the server-group portion of the schema complex, capable of applying overrides to the panoply of domain level constructs. Another approach is described in the discussion below:
emuckenhuber: yeah, plus we might also be missing some (reverse) tracking of configuration to servers ?
[11:33am] emuckenhuber: so when you say i wanna change a datasource - we should be able to figure out where it applies
[11:34am] bstansberry: yes
[11:34am] emuckenhuber: maybe that's what they meant with "common resource" updates
[11:35am] emuckenhuber: although it might work with server-groups - since they should be homogeneous... just that we would need an atomic operation spanning more server-groups?
[11:35am] bstansberry: right
[11:36am] bstansberry: what's trickier is if what if they only want to change on server group 1?
[11:36am] emuckenhuber: yeah, then we need to add a new datasource and change the mapping - or some sort of that...
[11:36am] bstansberry: right, which is pretty heavy
[11:37am] bstansberry: well, not that heavy
[11:37am] bstansberry: except we have to be smart enough to realize that if the change doesn't require datasource restart
[11:38am] bstansberry: that "add new datasource and change mapping" != undeploy datasource and deploy new one
[11:40am] emuckenhuber: yeah, we really need to figure out the interactions with the actual domain model
[11:40am] emuckenhuber: because a simple diff does not seem to tell those semantics
[11:44am] bstansberry: well, let's assume that the domain model / schema whatever provides us info on whether changing property foo can be done without a restart
[11:44am] bstansberry: if they wanted to do a server-group level change, the DC would have to
[11:44am] bstansberry: 1) create new domain resource
[11:44am] bstansberry: 2) map to server-group
[11:45am] bstansberry: 3) push a command to servers saying "ds x is now to be known as ds y and here's a property change to apply"
[11:47am] bstansberry: so that command differs from the "update ds across the entire domain" case by including the "ds x is now to be known as ds y" bit
[11:48am] emuckenhuber: hmm, yeah we might also need that for a single server ?
[11:49am] emuckenhuber: so domain / server-group / server wide update
[11:51am] bstansberry: in Westford we were wanting to rather severely limit server-level overrides
[11:51am] emuckenhuber: yes, i would prefer that as well
[11:51am] bstansberry: i.e. it's a fixed API for the server