2 Replies Latest reply on Jul 16, 2010 11:04 AM by Jason Greene

    Overriding domain level configurations at the server-group level

    Brian Stansberry Master

      Our 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
        • 1. Re: Overriding domain level configurations at the server-group level
          Emanuel Muckenhuber Master

          One other important issue which was raised on the call was the overlap of functionality between AS native management infrastructure (ServerManager, DomainController) vs. JON. Especially since the domain model per se is going to provide a pre-defined structure of your heterogeneous "network" - where JON most likely will not have much flexibility to temporarily change this structure. In the end this means that we basically have to implement a lot of the functionality currently in JON to provide their views and functionality - degrading JON to more a servlet, only showing the current domain state. Also as far as the current domain designs go, it seems that the domain controller is sort a separate server itself - this IMHO means that it is kind of a management server thing. Where i'm not sure if this really should be the responsibility of AS to provide this?

           

          Maybe it's just me seeing this as a problem?

          • 2. Re: Overriding domain level configurations at the server-group level
            Jason Greene Master

            Emanuel Muckenhuber wrote:

             

            One other important issue which was raised on the call was the overlap of functionality between AS native management infrastructure (ServerManager, DomainController) vs. JON. Especially since the domain model per se is going to provide a pre-defined structure of your heterogeneous "network" - where JON most likely will not have much flexibility to temporarily change this structure. In the end this means that we basically have to implement a lot of the functionality currently in JON to provide their views and functionality - degrading JON to more a servlet, only showing the current domain state. Also as far as the current domain designs go, it seems that the domain controller is sort a separate server itself - this IMHO means that it is kind of a management server thing. Where i'm not sure if this really should be the responsibility of AS to provide this?

             

            Maybe it's just me seeing this as a problem?

             

            Was Charles on this call?

             

            In the past he has favored moving the domain control stuff into AS (as we have been discussing/planning), and having JON focus on the larger harder problems (multi-product/mult-version/multi-domain/provisioning/etc). Under this model the embedded console is certainly just a "servlet", as it is only one of the agreed upon APIs in the domain model.