Re: [wildfly-dev] Management model attribute groups

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.