[wildfly-dev] Management model attribute groups

[Brian Stansberry]

On 12/10/14, 10:18 AM, Dev Ops wrote:
>
>
> On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> 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 <mailto: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.
>
>
> In your preamble you said:
>
> [...] 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. [...]
>
> Doesn't it clash with your last thought?
>

I don't think so. Attributes can be independently configurable, but it's 
still valid for a user to want to change several of them in a single 
atomic operation. Users can do that via a CLI batch, which internally 
uses the low-level "composite" operation (which is used by the console 
as well). This "write-attributes" op is just a different syntax to 
atomically update several things. It's much less verbose than doing the 
same thing with batch/composite but is limited to a single use case of 
changing several attributes on the same resource.

Of course if you want to change several attributes each on several 
different resources you could use batch/composite in combination with 
write-attributes and save quite a bit of typing.

>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


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