[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 5:14 PM, Jason Greene wrote:
>
>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>> 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.
>
> Hmm that nested syntax is an orthogonal feature IMO. I think that requires a lot more thought, as its basically inventing another nested dmr-path grammar. Not to say that we shouldn’t have that I just see rabbit hole there.
>

Weird timing. I'm writing the JIRA for "write-attributes", trying to be 
precise, and I just now hit that rabbit hole.

We already have the syntax, but it's used in the *value* of the "name" 
parameter to "write-attribute". Here we are using it in the parameter 
*name*. That makes it impractical to have a proper list of 
request-properties (aka params) in the read-operation-description output 
for the write-attributes op registered against a given address. Without 
that syntax, the parameter list would look much like the parameters for 
the resource's "add" operation.

Further down the rabbit hole, thinking about this earlier I realized the 
read-operation-description output for the "write-attribute" operation is 
not as good as it could be. For any given resource, the description of 
the "name" parameter could/should include the legal values, i.e. the 
names of the writable attributes. We don't do that, and now we really can't.


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