[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 11:44 AM, David M. Lloyd wrote:
> Forgot to hit "reply to list" on this one.
>
> On 12/10/2014 10:30 AM, Brian Stansberry wrote:
>> On 12/10/14, 10:06 AM, David M. Lloyd wrote:
>>> 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.
>>
>> Did you mean "should NOT allow"?
>
> No, I mean multiple levels _should_ be allowed, just with multiple
> qualifiers.  Multiple attribute writing per resource _should_ be allowed
> regardless of the depth or mixture of nesting.
>
> I.e. I should be able to do something like :write-attributes({"foo" =
> 123, "bar.baz.zap" = "hello"}) as one operation, with no special regard
> necessary to deal with attribute group navigation.
>

Gotcha, and I agree. Thanks for clarifying.

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