[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 5:37 PM, David M. Lloyd wrote:
> On 12/10/2014 05:35 PM, Brian Stansberry wrote:
>> 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)
>
> I guess I missed a beat; why can't we do the latter?  Is it because of
> the way we describe operations?  IMO this operation should be on an
> equal footing with adding resources and we should have a uniform means
> to describe it as such.
>

We describe the parameters to operations, including their names, and for 
all cases up to now those are easily and statically known. The CLI 
validates the parameter names used in low-level ops against the description.

This can be solved by analyzing any complex attributes and outputing all 
valid paths, using syntax like [] or [?] or [*] to indicate path 
segments that represent elements in a list. We don't allow '.', '[' or 
']' in attribute/field names, so the presence of the [ is enough to 
indicate that a list element is being described; the remaining ']', '?]' 
or '*]' are just to improve readability. I prefer a simple '[]'.

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