Re: [wildfly-dev] Management model attribute groups

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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.