5 Replies Latest reply on Sep 7, 2010 10:27 AM by brian.stansberry

    model updates and references

    emuckenhuber
      Last week we started some discussions about model updates and how updates affect other model elements e.g. subsystems referencing socket-bindings, or thread-pools. Where changes can be associated with certain group operations and the ability to validate at least parts of the model before pushing the updates to the individual groups or servers.
      I've been looking into making this part of the domain model, however i'm not really convinced if this what we want to do in the end. The current way of determining differences between two models seems to be sufficient in terms of updating and persisting model back to xml, but not for the actual runtime management part.
      In general there seem to be two options. Either we extend the notion of creating the difference of the model - meaning adding things like:
      - classify changes by group (profiles and subsystem, server-groups, host, server)
         So that if a subsystem get's modified we can figure out based on the profile which server groups are affected.
      - references and consumers
         e.g. when you change the value of a socket binding we should be able to figure out in which subsystems/profiles those are used
      - rename operations
         e.g. you change a server-group name, thread pool name, profile name
      - flag indicating that this change requires a restart
      - validation
      So i'm not sure if all this really make sense to add all this in getDifference()... Or have this part of a separate management layer, which basically means that the domain model cannot be used for runtime management directly... Where also the question is how would this should look like, since it would either be a sort of indirection layer or duplication of the domain model?
        • 1. Re: model updates and references
          brian.stansberry

          I see us having a separate layer, not doing modifications directly on the core model. But we need to start actually fleshing this out to see how it works.  I want to start with deployments; perhaps you can identify one or two more types of modifications that are fairly representative of different types of problems we need to handle?

           

          David might want to comment further, but I think we should look at the AbstractModelElement.appendDifferences() method as an initial idea on how to deal with updates, something we can supplement or even move away from completely. It's based on the idea that we have another instance of the model and we then calculate differences and based on those create update actions. It's not clear where that other instance of the model comes from. One of the nice aspects of the appendDifferences idea is only update classes have access to the package-protected modifier methods on the model objects. But then how is the other instance of the model created?

           

          Re: validation -- forgive me for a bit of a tangent: even with the more limited task we've done up to now of creating model objects by parsing, I think we're missing an explicit validation phase. For one thing, it's needed to give model elements a chance to resolve any references to other model elements. I've done a bit of that with RefResolver being passed into model element constructors, but there are cases where it's not valid to try and resolve the reference in the constructor (since the referent may not have been parsed yet). Now we're not resolving until the element is activated, which is too late.

           

           

          When we talked a week or so ago about a proper reference notion, I was thinking mostly in terms of the rename use case. So if socket-binding "foo" gets renamed "bar", any referring elements are aware of that and change their config to read "bar". But I think a richer reference notion can apply to other problems as well. For example, ServerGroupElement has a fully fleshed out "reference object" linking it to a ProfileElement. So if the ProfileElement is changed (either directly or via a change to a child subsystem) the ServerGroupElement is aware of that. We then use that information to figure out what to push out to the ServerManagers (and on to the Servers).

          • 2. Re: model updates and references
            emuckenhuber


            Brian Stansberry wrote:

             

            I see us having a separate layer, not doing modifications directly on the core model. But we need to start actually fleshing this out to see how it works.  I want to start with deployments; perhaps you can identify one or two more types of modifications that are fairly representative of different types of problems we need to handle?

             

            Yeah, i do think that a separate layer would be more interesting. At least changes should be decoupled from the core model - what i mean is that if you have someone editing the domain configuration, we should do a diff based on the edited "version" and then only apply the changes to the core domain model.
            Hmm some modifications i have in mind are:
            -) subsystem updates - since they are part of extensions
            -) creating new subsystems - since they might require an <extension /> module
            -) a domain deployment used by 2 server-groups... where you update only one group with a new deployment
            -) changing the value of a socket binding / jvm and determining which server-groups / servers are affected
            -) a deployment targeted to a single server - which would require to split the server-group? not sure if we want to allow that, but we had some discussions with the console team about that

             

            Brian Stansberry wrote:

             

            David might want to comment further, but I think we should look at the AbstractModelElement.appendDifferences() method as an initial idea on how to deal with updates, something we can supplement or even move away from completely. It's based on the idea that we have another instance of the model and we then calculate differences and based on those create update actions. It's not clear where that other instance of the model comes from. One of the nice aspects of the appendDifferences idea is only update classes have access to the package-protected modifier methods on the model objects. But then how is the other instance of the model created?

            I do like the diff update actions - so that might be the best way moving forward with modifications. However it's a bit unclear since the domain model is not really consistent at the moment.

             

            appendDiff() seems to be the first thing which needs to be changed  - since AbstractModel.synchronize(AbstractModel model) is always doing update.applyUpdate(AbstractModel model) on a List<AbstractModelUpdate<?>>. So i guess we would need to have sort of hierarchical updates where each modification maintains a list of updates for it's sub components? At least we should be able to use this as a way to determine whether a profile / subsystem has changed or not.

             

            Brian Stansberry wrote:

             

            Re: validation -- forgive me for a bit of a tangent: even with the more limited task we've done up to now of creating model objects by parsing, I think we're missing an explicit validation phase. For one thing, it's needed to give model elements a chance to resolve any references to other model elements. I've done a bit of that with RefResolver being passed into model element constructors, but there are cases where it's not valid to try and resolve the reference in the constructor (since the referent may not have been parsed yet). Now we're not resolving until the element is activated, which is too late.

             

            When we talked a week or so ago about a proper reference notion, I was thinking mostly in terms of the rename use case. So if socket-binding "foo" gets renamed "bar", any referring elements are aware of that and change their config to read "bar". But I think a richer reference notion can apply to other problems as well. For example, ServerGroupElement has a fully fleshed out "reference object" linking it to a ProfileElement. So if the ProfileElement is changed (either directly or via a change to a child subsystem) the ServerGroupElement is aware of that. We then use that information to figure out what to push out to the ServerManagers (and on to the Servers).

            Yes, i was thinking of a richer notion of references - especially since we have a lot of elements which are referenced in the domain model. Where one part would be - beeing able to validate the domain model as well as figuring out if a configuration update needs to be pushed to e.g. server-group. Although i haven't really thought about merging and activation - which is basically what the RefResolver is used for as well...

             

            Re: renaming - i think this is an operation which does not really fit into appendDiff() / calculateDiff() - if it's only a remove() and add() we would only know that that the model is not valid anymore, however we would loose the information about the renaming part.

            I need to think about the actual management API a bit more though...

            • 3. Re: model updates and references
              brian.stansberry

              Emanuel Muckenhuber wrote:


              Hmm some modifications i have in mind are:
              -) subsystem updates - since they are part of extensions
              -) creating new subsystems - since they might require an <extension /> module
              -) a domain deployment used by 2 server-groups... where you update only one group with a new deployment
              -) changing the value of a socket binding / jvm and determining which server-groups / servers are affected
              -) a deployment targeted to a single server - which would require to split the server-group? not sure if we want to allow that, but we had some discussions with the console team about that

               

              That seems like a good list, except for the last one. That's OK, too, but I was just now thinking that kind of thing should be decomposed into 2 steps: forming a new server-group from a set of servers, and then applying any change to that new server group. So the deployment becomes one type of change. All the servers that form a new server group would need to be consistent. They wouldn't need to come from the same server-group (although we could require that to make life easier) but their configurations would need to be consistent.

              • 4. Re: model updates and references
                emuckenhuber

                I pushed some work regarding model references and validation in a 'model-ref' branch on github. I basically just copied a part of the domain model into the domain-controller module (since it was empty), since i want to discuss that before merging it into the actual model. At the moment it's just doing validation, but could also be used for decoupling model updates from the actual model using references. This however depends mostly on how much of the model we want to expose for runtime management. In general i think it would make sense to separate the runtime view on the domain from the model. Maybe you can briefly look at that and see if that makes sense and we can discuss where we are going with that.

                I pushed some work regarding model references and validation in a 'model-ref' branch on github. I basically just copied a part of the domain model into the domain-controller module (as it was empty), since i want to discuss that before merging it into the actual model. At the moment it's just doing validation, but could also be used for decoupling model updates from the actual model using references. This however depends mostly on how much of the model we want to expose for runtime management. In general i think it would make sense to separate the runtime view on the domain from the model. Maybe you can briefly look at that and see if that makes sense and we can discuss further steps.

                 

                • 5. Re: model updates and references
                  brian.stansberry

                  I'll have a look today.