[jboss-as7-dev] Recent profile changes

[Brian Stansberry]

On 6/29/11 11:11 AM, Kabir Khan wrote:
>
>
> On 29 Jun 2011, at 16:57, Brian Stansberry wrote:
>
>> On 6/29/11 2:45 AM, Heiko W.Rupp wrote:
>>> Hey,
>>>
>>> Am 28.06.2011 um 13:08 schrieb Heiko Braun:
>>>> The recently introduced split into "ha", "default" and "web-base" profiles,
>>>> excludes a lot of the subsystems (messaging, ws, etc)
>>>
>>> On a related note: "default" includes "web-base".
>>
>> Note that for 7.0 we removed the used of<include/>.
>>
>>> What are the expected semantics when I run default for one SG and
>>> web-base for another and I want to e.g. change the web-http-connector
>>> port for default to 18080 and want to leave it as is on web-base?
>>>
>>> Does the server support copy on write?
>>>
>>
>> The intent is that an element in a profile or socket-binding-group takes
>> precedence over the same-named element from an included profile or
>> socket-binding-group. So if you added an http port config to
>> socket-binding-group "default", that would take precedence.
>>
>> I don't want to attempt to do any sort of fine-grained merging, i.e. if
>> there is a subsystem=web config in a "default" profile, that and only
>> that config is used on any server running the "default" profile; any
>> details from any subsystem=web in "web-base" would be ignored.
>>
>> Re: copy-on-write, doing a lot of stuff automagically in this area makes
>> me nervous. If a user intends to change subsystem=web only on the
>> servers running "default" I think they should have to take explicit
>> action to make that happen. That could be as simple as addressing their
>> change to /profile=default/subsystem=web instead of
>> /profile=web-base/subsystem=web, but there needs to be something.
>>
>> That said, assuming the user somehow indicates that only changing the
>> "default" profile is their intent, a copy-on-write approach sounds good.
>> It may make it much easier to apply a change to the servers (which know
>> nothing about multiple profiles and includes; a server just knows it was
>> given a config for subsystem=web.)
>>
>> Thinking out loud here:
>>
>> Ike mentions wanting<include/>  to just be syntactic sugar in the xml.
>> So if profile=default includes profile=web-base and web-base has
>> subsystem=web, that would largely be relevant in the xml. Looking at the
>> management resources, you would see:
>>
>> /profile=web-base/subsystem=web
>> /profile=default/subsystem=web
>>
>> The<include profile="web-base"/>  in the XML would just be a trigger to
>> the parser to generate those resources in the model.
>>
>> Changes to /profile=default/subsystem=web would result in that subsystem
>> now being persisted in the<profile name=default>  section of the xml.
>> (What magic would trigger that persistence: TBD. Perhaps the in-memory
>> model for the subsystem includes an included-from-profile="web-base"
>> attribute, and the presence of that attribute disable persistence to xml.)
>>
>> Trickier would be a change to /profile=web-base/subsystem=web. What's
>> the user intent there? Should servers running profile=default be updated
>> as well, and the syntactic sugar in the xml be maintained? Or is
>> /profile=default/subsystem=web now decoupled from
>> /profile=web-base/subsystem=web?
>
> I like having the subsystems managed centrally, and think included profiles should be "included" only. If we want subsystems from an included profile to be displayed in the including profile (the syntactic sugar), maybe add an additional attribute on subsystem such as source-profile="web-base", or included="true"?

I had included-from-profile="web-base" above, but 
source-profile="web-base" is better.

That way we can stop them from being edited in any other place than the 
source profile. We could also prevent them from appearing in the 
read-resource results unless an additional parameter (e.g. 
include-included) is true.

We'd have to apply that param to all the relevant global operations 
(read-children-names etc). It also becomes a universal parameter that is 
only meaningful when certain addresses are involved. These aren't 
blocker problems, just things to be aware of.  A blocker issue would be 
coming up with a better name. ;)

CLI navigation could be a problem here; you can do a 
:read-children-names(include-included=true) but then can't navigate. 
Unless we had logic on the server side to recognize that...

/profile=default/subsystem=web:read-resource

really means to read /profile=web-base/subsystem=web and then stick 
source-profile="web-base" in the response.

If they want to override subsystem stuff in the including profile, we 
could provide a copy function that needs to be called explicitly to do 
the decoupling of the subsystem.

Ok, so you've defined the boundaries of a "no auto-magic, require the 
user to clearly state their intent" approach, which is good.

I'm curious to hear other viewpoints.

>
>>
>> One not totally satisfying way to clarify things is to have a notion of
>> an "abstract" profile. An abstract profile cannot be applied to a server
>> group. A change to an abstract profile applies to all profiles that
>> include it and don't themselves override the relevant subsystem. Other
>> profiles could only include abstract profiles.
>>

WDYT about this 'abstract' notion? Whether or not we require a 'copy' 
operation to decouple the included subsystem, I don't like having a 
profile be both inherited and directly applied to servers. It makes it 
too difficult to determine the user's intent when they modify the profile.

>> </end-brain-dump>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat