[wildfly-dev] Management model attribute groups

[Dev Ops]

On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry <
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>
> 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?


>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141210/e33faf89/attachment.html