-
1. Re: model updates and references
brian.stansberry Aug 30, 2010 11:25 AM (in response to emuckenhuber)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 Aug 30, 2010 2:08 PM (in response to brian.stansberry)
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 thatBrian 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 Aug 31, 2010 5:24 PM (in response to emuckenhuber)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 thatThat 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 Sep 7, 2010 8:41 AM (in response to brian.stansberry)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 Sep 7, 2010 10:27 AM (in response to emuckenhuber)I'll have a look today.