[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 5:27 PM, Brian Stansberry wrote:
> 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.
>

I gave up writing up the JIRA, as I want it to be precise and it can't 
be precise enough until we have a good solution to this question. An 
ugly one is:

:write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])

That's a lot more confusing and verbose than

:write-attributes(foo=123,bar.baz.zap=hello)



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