[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?

This is what I meant by

"4) Low level management API

The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name."

I used the verb "sorted" though because I have no intent of modifying 
the output structure by creating a level for the attribute group. That 
would be an incompatible change in the output format and would obscure 
the distinction between an attribute group and a complex attribute.

> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>

Good question.

Heiko, I don't think Emmanuel is talking about users changing this. We 
use aliasing in other contexts as a mechanism for maintaining 
compatibility. If something is poorly named (e.g. a bad resource address 
name) we can fix it in a later release but also register an alias under 
the old name to provide compatibility.

I don't see how aliasing could work here. Only thing I can imagine is 
using it in the ls -l output, such that the same attribute can appear > 
1 times, if it is associated with more than 1 group. I suppose a console 
could do a similar thing, but I don't at all regard maintaining that 
kind of compatibility in UI layout to be a requirement.

I'm not sure how much we regard consistency in the ls -l output across 
releases as being a requirement. I think of that as being an output 
format for humans, not machines.

Aliasing is an example of a reason for allowing an attribute to belong 
to more than one group. There may be others. Perhaps as an aid to querying?

> Emmanuel
>
>
> Le 09/12/2014 21:00, Brian Stansberry a écrit :
>> Off and on we've had discussions around the idea of "attribute groups".
>> We've got some use cases that are crying out for such a thing[1], so I'd
>> like to propose doing something concrete but simple for these for WF 9,
>> ideally in the next month.
>>
>> A big part of my goal here is to ensure that whatever we do doesn't
>> preclude something more advanced in any next generation management
>> stuff, e.g. David's stuff.
>>
>> PART I Concepts
>>
>> 1) What is an attribute group?
>>
>> The "attribute group" concept I propose is simply a collection of
>> attributes associated with the same resource type that are independently
>> configurable but are statically declared to be conceptually related. The
>> group has a name, and members. The name provides a brief indication of
>> the nature of the relationship.
>>
>> The goal is to provide information to the user to help them better
>> understand the relationship between attributes. In particular,
>> management tools could use this information to visually present related
>> attributes together, e.g. in a tab or other grouping widget in the web
>> console.
>>
>> 2) What isn't an attribute group?
>>
>> Something relevant to writes.
>>
>> 3) Why would I use a child resource instead of an attribute group?
>>
>> Because the attributes control a discrete piece of functionality and you
>> need to be able to turn that on or off as a unit. So you add/remove the
>> resource.
>>
>> 4) Why would I use a complex attribute with a bunch of fields instead of
>> n>1 simple attributes in a group.
>>
>> a) Because the attributes control a discrete piece of functionality and
>> you need to be able to turn that off as a unit. So users can undefine
>> the complex attribute.
>>
>> b) Because it's a common use case that modifications to n>1 of the
>> fields should be done atomically and you don't want to force users to
>> use a CLI batch. So you let them use write-attribute and specify the
>> value of all the fields.
>>
>> 5) Why would I use an attribute group instead of a child resource?
>>
>> Because requiring users to add a child resource just to set a bunch of
>> values that are really part of the config of the parent resource forces
>> them to use a CLI batch to correctly configure the parent resource.
>>
>> 6) Why would I use an attribute group instead a complex attribute?
>>
>> Because the various attributes should be independently configurable. In
>> particular, wiping out the config for all of them by simply undefining
>> the complex attribute isn't appropriate.
>>
>> PART II Proposed Work
>>
>> 1) The basics
>>
>> We add a piece of metadata to the read-resource-description output for
>> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
>> value is the name of the group, with 'undefined' allowed.
>>
>> The group is simply the set of attributes that share the same string.
>>
>> To implement this, we add public String
>> AttributeDefinition.getAttributeGroup() and add support for setting it
>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>>
>> 2) XML parsing/marshalling
>>
>> Modify PersistentResourceXMLDescription such that attributes in an
>> attribute group get persisted in their own child element, whose name is
>> the name of the group.
>>
>> PersistentResourceXMLBuilder exposes a setter to allow users to turn
>> this on/off for that resource. Turning it off will allow the addition of
>> attribute group settings for a resource without requiring an immediate
>> corresponding xsd change.
>>
>> 3) Web console
>>
>> HAL can make use of the additional metadata at its leisure, and as it
>> becomes available.
>>
>> 4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name.
>>
>> 5) CLI
>>
>> I'm not clear on exactly what to do here, but my instinct is the output
>> of the 'ls -l' command should be modified. Probably add a GROUP column
>> to the right and sort the order of attributes by group and then by
>> attribute name.
>>
>> PART III Other possible things to do
>>
>> A :read-attribute-group(name=<groupname>) operation or an
>> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
>> convenient to read a set of attributes without needing to read the
>> entire resource.
>>
>> We could also consider adding an "attribute-groups" section to the
>> read-resource-description output, where a fuller i18n text description
>> of the meaning of the group could be written. If we do this we should
>> probably do it in WF 9 as it will likely add some sort of requirement to
>> subsystem authors that we expose right from the start.
>>
>>
>> If you're still awake, comments as always are appreciated.
>>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat