Re: [wildfly-dev] Management model attribute groups

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.