[wildfly-dev] Management model attribute groups

[David M. Lloyd]

On 12/10/2014 09:52 AM, Brian Stansberry wrote:
> On 12/10/14, 9:22 AM, Kabir Khan wrote:
>>
>>> On 9 Dec 2014, at 21:00, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>>
>>> 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.
>> Why not something along the lines of :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})?
>> Internally that could create a composite for us, giving complex attribute functionality while avoiding the messy resource descriptions
>>
>
> On the branch of the thread where I'm discussing with Tomaz, he raised
> the same idea, which I think is a good one. I think a "write-attributes"
> with no relationship to attribute-group makes more sense though.

I agree.  I have always felt that we should allow more than level of 
grouping.  Having a special operation that "knows about" attribute 
groups in some special way is thus precluded; simply having a multiple 
"write-attributes" fits in nicely with the concept that a resource is 
actually our basic atomic unit of granularity.

-- 
- DML