[jboss-as7-dev] Recent profile changes

[Brian Stansberry]

On 7/4/11 10:11 AM, David M. Lloyd wrote:
> Inline.
>
> On 07/04/2011 02:50 AM, Heiko Braun wrote:
>>
>> Makes sense from your point of view, but for tools or users it's difficult to maintain
>> the proper source address and dealing with circular references.
>>
>> Let's say profile B includes profile A. Profile A declares subsystem Foo.
>>
>> Can we support both?
>>
>> /profile=B/subsystem=Foo:write-attribute
>>
>> and
>>
>> /profile=A/subsystem=Foo:write-attribute
>
> I would say "no".  This not only makes sense from our point of view but
> yours as well.  If they change an attribute in an inheriting profile, it
> will change it for the other profile as well, and for all profiles which
> include that profile, which can cause some major surprise.
>

Agreed. After thinking about this thread over the weekend, I'd now say 
"absolutely no", at least not without an intermediate step or steps that 
explicitly indicate that /profile=B/subsystem=Foo is now a complete 
replacement of /profile=A/subsystem=Foo, e.g.

/profile=B:copy(subsystem=Foo)

>> The point is that for most management tasks, it doesn't matter that the effective profile
>> actually consists of an inclusion hierarchy. I believe people care about the subsystem "Web" configuration
>> for a particular server, regardless of it's origin. So forcing them to deal with the inclusion hierarchy
>> doesn't make sense to me. I don't see the added value.
>>

Let's talk a bit about the intended use case for this <include/> 
feature. There's an obvious use case, and then the IMHO more important 
one, and we should document the distinction and tailor our solution 
around properly supporting the more important one.

The obvious use case is to save some xml by inheriting configuration.

The more important one is an admin saying that servers running profiles 
B, C, and D should all be getting their subsystem Foo configuration from 
profile A because the configuration in profile A is tested and correct 
and we know it's the one we want and we don't intend to alter it between 
different server groups. Absolutely the junior admin on the night shift 
shouldn't be able to break that consistency by mindlessly doing 
/profile=B/subsystem=Foo:write-attribute

Best practice should be to not create an inheritance hierarchy between 
profiles unless you fully expect that relationship to remain unchanged 
for the long term, as it will not be a trivial thing to break the 
relationship. At best it will require something like the "copy" 
operation I mention above; at worst it requires an entire new profile 
and a restart of all affected servers.

IMO we should never have an <include/> in any of the config files we 
ship ourselves, as our reason for doing it would solely be

>> Apart from that there are other, related questions that we need address:
>>
>> - Are subsystem re-declarations allowed within an inclusion hierarchy?
>
> IIRC No.
>

The original intent was to not allow this. The rationale for allowing it 
would only be to allow a profile to break one subsystem out of the 
inheritance relationship without requiring a completely new profile and 
a full restart of the affected servers.

I was going to say this could be added in a later release, and that's 
somewhat true. But, e.g. a host controller running 7.1 in a domain run 
by a domain controller running 7.2 would not be able to handle this.

>> - What's the policy for this: replace or merge?
>>

Absolutely it would be a replace if allowed at all. If merges were 
supported they would have to be implemented by the subsystem devs and 
the chances of that being done correctly and maintained correctly over 
time by all subsystems are less than zero. ;-) A replace could be 
handled by the core domain infrastructure.


>> I think once these questions are answered we'll easily find a solution to the questions above.
>>
>> Ike
>>
>>
>> On Jul 2, 2011, at 11:56 AM, Kabir Khan wrote:
>>
>>> I prefer it the way we have it set up now, but with the ability to see but not modify inherited stuff easily.
>>
>>
>> _______________________________________________
>> 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