Management model attribute groups

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Management model attribute groups

Brian Stansberry
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.

5) Why would I use an attribute group instead of a child resource?

Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.

6) Why would I use an attribute group instead a complex attribute?

Because the various attributes should be independently configurable. In
particular, wiping out the config for all of them by simply undefining
the complex attribute isn't appropriate.

PART II Proposed Work

1) The basics

We add a piece of metadata to the read-resource-description output for
an attribute. Name is 'attribute-group', value type is ModelType.STRING,
value is the name of the group, with 'undefined' allowed.

The group is simply the set of attributes that share the same string.

To implement this, we add public String
AttributeDefinition.getAttributeGroup() and add support for setting it
to the relevant Builder. ReadResourceDescriptionHandler outputs the value.

2) XML parsing/marshalling

Modify PersistentResourceXMLDescription such that attributes in an
attribute group get persisted in their own child element, whose name is
the name of the group.

PersistentResourceXMLBuilder exposes a setter to allow users to turn
this on/off for that resource. Turning it off will allow the addition of
attribute group settings for a resource without requiring an immediate
corresponding xsd change.

3) Web console

HAL can make use of the additional metadata at its leisure, and as it
becomes available.

4) Low level management API

The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name.

5) CLI

I'm not clear on exactly what to do here, but my instinct is the output
of the 'ls -l' command should be modified. Probably add a GROUP column
to the right and sort the order of attributes by group and then by
attribute name.

PART III Other possible things to do

A :read-attribute-group(name=<groupname>) operation or an
"attribute-groups=[<groupname>*]" param to :read-resource, to make it
convenient to read a set of attributes without needing to read the
entire resource.

We could also consider adding an "attribute-groups" section to the
read-resource-description output, where a fuller i18n text description
of the meaning of the group could be written. If we do this we should
probably do it in WF 9 as it will likely add some sort of requirement to
subsystem authors that we expose right from the start.


If you're still awake, comments as always are appreciated.

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

[1] For example, the JDKORB pull request at
https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
number of places where it seems like attribute groups are a better fit.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

jtgreene
Administrator
This proposal is a great idea. Let’s do it :)

> On Dec 9, 2014, at 2:00 PM, Brian Stansberry <[hidden email]> 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.
>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 4) Low level management API
>
> The output of read-resource and read-resource-description is modified
> such that attributes are sorted by group name and then by attribute name.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
> [1] For example, the JDKORB pull request at
> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
> number of places where it seems like attribute groups are a better fit.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Heiko Braun
In reply to this post by Brian Stansberry
+1 i am all for it. Including read-attribute-group(). But i would as well add a read-attribute-group-names() operation to complete the picture.




> Am 09.12.2014 um 21:00 schrieb Brian Stansberry <[hidden email]>:
>
> read-attribute-group

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Emmanuel Hugonnet
In reply to this post by Brian Stansberry
Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
Is aliasing to be supported ?  What if I want to change the attribute group name ?

Emmanuel


Le 09/12/2014 21:00, Brian Stansberry a écrit :

> 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.
>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 4) Low level management API
>
> The output of read-resource and read-resource-description is modified
> such that attributes are sorted by group name and then by attribute name.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Heiko Braun
Changing group names is not user space Api. Users can map internal names to custom titles, if needed.




> Am 10.12.2014 um 10:59 schrieb Emmanuel Hugonnet <[hidden email]>:
>
> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>
> Emmanuel
>
>
> Le 09/12/2014 21:00, Brian Stansberry a écrit :
>> 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.
>>
>> 5) Why would I use an attribute group instead of a child resource?
>>
>> Because requiring users to add a child resource just to set a bunch of
>> values that are really part of the config of the parent resource forces
>> them to use a CLI batch to correctly configure the parent resource.
>>
>> 6) Why would I use an attribute group instead a complex attribute?
>>
>> Because the various attributes should be independently configurable. In
>> particular, wiping out the config for all of them by simply undefining
>> the complex attribute isn't appropriate.
>>
>> PART II Proposed Work
>>
>> 1) The basics
>>
>> We add a piece of metadata to the read-resource-description output for
>> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
>> value is the name of the group, with 'undefined' allowed.
>>
>> The group is simply the set of attributes that share the same string.
>>
>> To implement this, we add public String
>> AttributeDefinition.getAttributeGroup() and add support for setting it
>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>>
>> 2) XML parsing/marshalling
>>
>> Modify PersistentResourceXMLDescription such that attributes in an
>> attribute group get persisted in their own child element, whose name is
>> the name of the group.
>>
>> PersistentResourceXMLBuilder exposes a setter to allow users to turn
>> this on/off for that resource. Turning it off will allow the addition of
>> attribute group settings for a resource without requiring an immediate
>> corresponding xsd change.
>>
>> 3) Web console
>>
>> HAL can make use of the additional metadata at its leisure, and as it
>> becomes available.
>>
>> 4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name.
>>
>> 5) CLI
>>
>> I'm not clear on exactly what to do here, but my instinct is the output
>> of the 'ls -l' command should be modified. Probably add a GROUP column
>> to the right and sort the order of attributes by group and then by
>> attribute name.
>>
>> PART III Other possible things to do
>>
>> A :read-attribute-group(name=<groupname>) operation or an
>> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
>> convenient to read a set of attributes without needing to read the
>> entire resource.
>>
>> We could also consider adding an "attribute-groups" section to the
>> read-resource-description output, where a fuller i18n text description
>> of the meaning of the group could be written. If we do this we should
>> probably do it in WF 9 as it will likely add some sort of requirement to
>> subsystem authors that we expose right from the start.
>>
>>
>> If you're still awake, comments as always are appreciated.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by Emmanuel Hugonnet
On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?

This is what I meant by

"4) Low level management API

The output of read-resource and read-resource-description is modified
such that attributes are sorted by group name and then by attribute name."

I used the verb "sorted" though because I have no intent of modifying
the output structure by creating a level for the attribute group. That
would be an incompatible change in the output format and would obscure
the distinction between an attribute group and a complex attribute.

> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>

Good question.

Heiko, I don't think Emmanuel is talking about users changing this. We
use aliasing in other contexts as a mechanism for maintaining
compatibility. If something is poorly named (e.g. a bad resource address
name) we can fix it in a later release but also register an alias under
the old name to provide compatibility.

I don't see how aliasing could work here. Only thing I can imagine is
using it in the ls -l output, such that the same attribute can appear >
1 times, if it is associated with more than 1 group. I suppose a console
could do a similar thing, but I don't at all regard maintaining that
kind of compatibility in UI layout to be a requirement.

I'm not sure how much we regard consistency in the ls -l output across
releases as being a requirement. I think of that as being an output
format for humans, not machines.

Aliasing is an example of a reason for allowing an attribute to belong
to more than one group. There may be others. Perhaps as an aid to querying?

> Emmanuel
>
>
> Le 09/12/2014 21:00, Brian Stansberry a écrit :
>> 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.
>>
>> 5) Why would I use an attribute group instead of a child resource?
>>
>> Because requiring users to add a child resource just to set a bunch of
>> values that are really part of the config of the parent resource forces
>> them to use a CLI batch to correctly configure the parent resource.
>>
>> 6) Why would I use an attribute group instead a complex attribute?
>>
>> Because the various attributes should be independently configurable. In
>> particular, wiping out the config for all of them by simply undefining
>> the complex attribute isn't appropriate.
>>
>> PART II Proposed Work
>>
>> 1) The basics
>>
>> We add a piece of metadata to the read-resource-description output for
>> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
>> value is the name of the group, with 'undefined' allowed.
>>
>> The group is simply the set of attributes that share the same string.
>>
>> To implement this, we add public String
>> AttributeDefinition.getAttributeGroup() and add support for setting it
>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>>
>> 2) XML parsing/marshalling
>>
>> Modify PersistentResourceXMLDescription such that attributes in an
>> attribute group get persisted in their own child element, whose name is
>> the name of the group.
>>
>> PersistentResourceXMLBuilder exposes a setter to allow users to turn
>> this on/off for that resource. Turning it off will allow the addition of
>> attribute group settings for a resource without requiring an immediate
>> corresponding xsd change.
>>
>> 3) Web console
>>
>> HAL can make use of the additional metadata at its leisure, and as it
>> becomes available.
>>
>> 4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name.
>>
>> 5) CLI
>>
>> I'm not clear on exactly what to do here, but my instinct is the output
>> of the 'ls -l' command should be modified. Probably add a GROUP column
>> to the right and sort the order of attributes by group and then by
>> attribute name.
>>
>> PART III Other possible things to do
>>
>> A :read-attribute-group(name=<groupname>) operation or an
>> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
>> convenient to read a set of attributes without needing to read the
>> entire resource.
>>
>> We could also consider adding an "attribute-groups" section to the
>> read-resource-description output, where a fuller i18n text description
>> of the meaning of the group could be written. If we do this we should
>> probably do it in WF 9 as it will likely add some sort of requirement to
>> subsystem authors that we expose right from the start.
>>
>>
>> If you're still awake, comments as always are appreciated.
>>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Tomaž Cerar-2
In reply to this post by Brian Stansberry

On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry <[hidden email]> wrote:
5) Why would I use an attribute group instead of a child resource?

Because requiring users to add a child resource just to set a bunch of
values that are really part of the config of the parent resource forces
them to use a CLI batch to correctly configure the parent resource.


One thing that I am not sure about this is, how do we do validation for things like this?

Simple example would be "required" validation for attribute group.
You want to enforce few attributes that are part of the group to be required.

but on other hand you don't want to enforce them as part of resource:add operation.
as they are only "required" when you are editing / adding attribute group.

With current code we enforce required for all attributes on a resource that is being added.
Which is bit inconvenient for when we have attribute groups and want to do it bit differently.

So question is should we support selective validation based on groups or not?


--
tomaz


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by jtgreene
On 12/9/14, 4:41 PM, Jason Greene wrote:
> This proposal is a great idea. Let’s do it :)
>

I can probably have a branch with the "Proposed Work" bit, excluding the
CLI ls -l thing, done today or tomorrow. It went quicker than I thought.
But the more important part is any discussion here. The CLI ls -l thing
I don't want to code yet because I don't have a strong feeling about
that solution.

>> On Dec 9, 2014, at 2:00 PM, Brian Stansberry <[hidden email]> 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.
>>
>> 5) Why would I use an attribute group instead of a child resource?
>>
>> Because requiring users to add a child resource just to set a bunch of
>> values that are really part of the config of the parent resource forces
>> them to use a CLI batch to correctly configure the parent resource.
>>
>> 6) Why would I use an attribute group instead a complex attribute?
>>
>> Because the various attributes should be independently configurable. In
>> particular, wiping out the config for all of them by simply undefining
>> the complex attribute isn't appropriate.
>>
>> PART II Proposed Work
>>
>> 1) The basics
>>
>> We add a piece of metadata to the read-resource-description output for
>> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
>> value is the name of the group, with 'undefined' allowed.
>>
>> The group is simply the set of attributes that share the same string.
>>
>> To implement this, we add public String
>> AttributeDefinition.getAttributeGroup() and add support for setting it
>> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>>
>> 2) XML parsing/marshalling
>>
>> Modify PersistentResourceXMLDescription such that attributes in an
>> attribute group get persisted in their own child element, whose name is
>> the name of the group.
>>
>> PersistentResourceXMLBuilder exposes a setter to allow users to turn
>> this on/off for that resource. Turning it off will allow the addition of
>> attribute group settings for a resource without requiring an immediate
>> corresponding xsd change.
>>
>> 3) Web console
>>
>> HAL can make use of the additional metadata at its leisure, and as it
>> becomes available.
>>
>> 4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name.
>>
>> 5) CLI
>>
>> I'm not clear on exactly what to do here, but my instinct is the output
>> of the 'ls -l' command should be modified. Probably add a GROUP column
>> to the right and sort the order of attributes by group and then by
>> attribute name.
>>
>> PART III Other possible things to do
>>
>> A :read-attribute-group(name=<groupname>) operation or an
>> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
>> convenient to read a set of attributes without needing to read the
>> entire resource.
>>
>> We could also consider adding an "attribute-groups" section to the
>> read-resource-description output, where a fuller i18n text description
>> of the meaning of the group could be written. If we do this we should
>> probably do it in WF 9 as it will likely add some sort of requirement to
>> subsystem authors that we expose right from the start.
>>
>>
>> If you're still awake, comments as always are appreciated.
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>> [1] For example, the JDKORB pull request at
>> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
>> number of places where it seems like attribute groups are a better fit.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by Tomaž Cerar-2
On 12/10/14, 8:23 AM, Tomaž Cerar wrote:

>
> On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     5) Why would I use an attribute group instead of a child resource?
>
>     Because requiring users to add a child resource just to set a bunch of
>     values that are really part of the config of the parent resource forces
>     them to use a CLI batch to correctly configure the parent resource.
>
>
>
> One thing that I am not sure about this is, how do we do validation for
> things like this?
>
> Simple example would be "required" validation for attribute group.
> You want to enforce few attributes that are part of the group to be
> required.
>
> but on other hand you don't want to enforce them as part of resource:add
> operation.
> as they are only "required" when you are editing / adding attribute group.
>
> With current code we enforce required for all attributes on a resource
> that is being added.
> Which is bit inconvenient for when we have attribute groups and want to
> do it bit differently.
>
> So question is should we support selective validation based on groups or
> not?
>

This sounds more like a complex attribute or a child resource. The
attributes control a discrete piece of functionality and
you need to be able to turn that on/off as a unit. The attributes are
required if that functionality is turned on.

>
> --
> tomaz
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Tomaž Cerar-2

On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry <[hidden email]> wrote:
This sounds more like a complex attribute or a child resource. The attributes control a discrete piece of functionality and
you need to be able to turn that on/off as a unit. The attributes are required if that functionality is turned on.

Agreed, but how do you handle scenario where you just add resource that has 30 attributes all in attribute groups.
You call :add() without any parameters as you plan to add/edit attributes that are part of attribute group in next step.
you than call :write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required, value="some-value")
and this should fail, as attribute is part of attribute group.

It is a tricky thing to address, as we have not atomic way to write/update more than one attribute at ones.
maybe have extra operation to do write-attribute-group(name="first-attribute-group", attr1=value,attr2=value) similar to :add semantics.

otherwise I don't see any good way to do atomic updates of whole attribute group.





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

kkhan
In reply to this post by Brian Stansberry

> On 9 Dec 2014, at 21:00, Brian Stansberry <[hidden email]> 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

>
> 5) Why would I use an attribute group instead of a child resource?
>
> Because requiring users to add a child resource just to set a bunch of
> values that are really part of the config of the parent resource forces
> them to use a CLI batch to correctly configure the parent resource.
>
> 6) Why would I use an attribute group instead a complex attribute?
>
> Because the various attributes should be independently configurable. In
> particular, wiping out the config for all of them by simply undefining
> the complex attribute isn't appropriate.
>
> PART II Proposed Work
>
> 1) The basics
>
> We add a piece of metadata to the read-resource-description output for
> an attribute. Name is 'attribute-group', value type is ModelType.STRING,
> value is the name of the group, with 'undefined' allowed.
>
> The group is simply the set of attributes that share the same string.
>
> To implement this, we add public String
> AttributeDefinition.getAttributeGroup() and add support for setting it
> to the relevant Builder. ReadResourceDescriptionHandler outputs the value.
>
> 2) XML parsing/marshalling
>
> Modify PersistentResourceXMLDescription such that attributes in an
> attribute group get persisted in their own child element, whose name is
> the name of the group.
>
> PersistentResourceXMLBuilder exposes a setter to allow users to turn
> this on/off for that resource. Turning it off will allow the addition of
> attribute group settings for a resource without requiring an immediate
> corresponding xsd change.
>
> 3) Web console
>
> HAL can make use of the additional metadata at its leisure, and as it
> becomes available.
>
> 4) Low level management API
>
> The output of read-resource and read-resource-description is modified
> such that attributes are sorted by group name and then by attribute name.
>
> 5) CLI
>
> I'm not clear on exactly what to do here, but my instinct is the output
> of the 'ls -l' command should be modified. Probably add a GROUP column
> to the right and sort the order of attributes by group and then by
> attribute name.
>
> PART III Other possible things to do
>
> A :read-attribute-group(name=<groupname>) operation or an
> "attribute-groups=[<groupname>*]" param to :read-resource, to make it
> convenient to read a set of attributes without needing to read the
> entire resource.
>
> We could also consider adding an "attribute-groups" section to the
> read-resource-description output, where a fuller i18n text description
> of the meaning of the group could be written. If we do this we should
> probably do it in WF 9 as it will likely add some sort of requirement to
> subsystem authors that we expose right from the start.
>
>
> If you're still awake, comments as always are appreciated.
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
> [1] For example, the JDKORB pull request at
> https://github.com/wildfly/wildfly/pull/7008 uses child resources in a
> number of places where it seems like attribute groups are a better fit.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by Tomaž Cerar-2
On 12/10/14, 9:05 AM, Tomaž Cerar wrote:

>
> On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     This sounds more like a complex attribute or a child resource. The
>     attributes control a discrete piece of functionality and
>     you need to be able to turn that on/off as a unit. The attributes
>     are required if that functionality is turned on.
>
>
> Agreed, but how do you handle scenario where you just add resource that
> has 30 attributes all in attribute groups.
> You call :add() without any parameters as you plan to add/edit
> attributes that are part of attribute group in next step.
> you than call
> :write-attribute(name=non-require-attribute-that-is-part-of-group-that-has-few-required,
> value="some-value")
> and this should fail, as attribute is part of attribute group.
>

You use a batch if it's important to you to format your request into
separate lines. Or you just include all the params and use the line
separator to break your add up into multiple lines and save a lot of typing.

(I'm not really arguing against you ^^^, just pointing out ways to do
things in case readers are not aware.)

> It is a tricky thing to address, as we have not atomic way to
> write/update more than one attribute at ones.
> maybe have extra operation to do
> write-attribute-group(name="first-attribute-group",
> attr1=value,attr2=value) similar to :add semantics.
>
> otherwise I don't see any good way to do atomic updates of whole
> attribute group.
>

Ok, I'll add this to the "Other possible things to do" bit. Thanks for
the input. :)

I think "write-attributes(attr1=value,attr2=value)" makes more sense
though. This is really syntactic sugar around updating multiple
attribute in one op, not requiring client-side creation of a composite.
There's no need to tie the concept to the attribute-group notion.

>
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by kkhan
On 12/10/14, 9:22 AM, Kabir Khan wrote:

>
>> On 9 Dec 2014, at 21:00, Brian Stansberry <[hidden email]> 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.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

David Lloyd-2
In reply to this post by Brian Stansberry
On 12/10/2014 08:21 AM, Brian Stansberry wrote:

> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
>
> This is what I meant by
>
> "4) Low level management API
>
> The output of read-resource and read-resource-description is modified
> such that attributes are sorted by group name and then by attribute name."
>
> I used the verb "sorted" though because I have no intent of modifying
> the output structure by creating a level for the attribute group. That
> would be an incompatible change in the output format and would obscure
> the distinction between an attribute group and a complex attribute.

FWIW I think this is a good distinction and a good approach.

>> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>>
>
> Good question.
>
> Heiko, I don't think Emmanuel is talking about users changing this. We
> use aliasing in other contexts as a mechanism for maintaining
> compatibility. If something is poorly named (e.g. a bad resource address
> name) we can fix it in a later release but also register an alias under
> the old name to provide compatibility.
>
> I don't see how aliasing could work here. Only thing I can imagine is
> using it in the ls -l output, such that the same attribute can appear >
> 1 times, if it is associated with more than 1 group. I suppose a console
> could do a similar thing, but I don't at all regard maintaining that
> kind of compatibility in UI layout to be a requirement.
>
> I'm not sure how much we regard consistency in the ls -l output across
> releases as being a requirement. I think of that as being an output
> format for humans, not machines.
>
> Aliasing is an example of a reason for allowing an attribute to belong
> to more than one group. There may be others. Perhaps as an aid to querying?

I still feel strongly that we should look to real resource versioning as
the proper solution here, though I realize there has not been a
satisfactory resolution to this discussion.  But the longer we don't
come to a resolution, the more (arguably questionable) tricks we have to
pull to manage compatibility.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

David Lloyd-2
In reply to this post by Brian Stansberry
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 <[hidden email]> 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.  Having a special operation that "knows about" attribute
groups in some special way is thus precluded; simply having a multiple
"write-attributes" fits in nicely with the concept that a resource is
actually our basic atomic unit of granularity.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Dev Ops
In reply to this post by Brian Stansberry


On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry <[hidden email]> wrote:
On 12/10/14, 9:22 AM, Kabir Khan wrote:
>
>> On 9 Dec 2014, at 21:00, Brian Stansberry <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by David Lloyd-2
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 <[hidden email]> 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"?

>  Having a special operation that "knows about" attribute
> groups in some special way is thus precluded; simply having a multiple
> "write-attributes" fits in nicely with the concept that a resource is
> actually our basic atomic unit of granularity.
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by Dev Ops
On 12/10/14, 10:18 AM, Dev Ops wrote:

>
>
> On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 12/10/14, 9:22 AM, Kabir Khan wrote:
>      >
>      >> On 9 Dec 2014, at 21:00, Brian Stansberry
>     <[hidden email] <mailto:[hidden email]>>
>     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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
In reply to this post by David Lloyd-2
On 12/10/14, 10:02 AM, David M. Lloyd wrote:

> On 12/10/2014 08:21 AM, Brian Stansberry wrote:
>> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
>>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
>>
>> This is what I meant by
>>
>> "4) Low level management API
>>
>> The output of read-resource and read-resource-description is modified
>> such that attributes are sorted by group name and then by attribute name."
>>
>> I used the verb "sorted" though because I have no intent of modifying
>> the output structure by creating a level for the attribute group. That
>> would be an incompatible change in the output format and would obscure
>> the distinction between an attribute group and a complex attribute.
>
> FWIW I think this is a good distinction and a good approach.
>
>>> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>>>
>>
>> Good question.
>>
>> Heiko, I don't think Emmanuel is talking about users changing this. We
>> use aliasing in other contexts as a mechanism for maintaining
>> compatibility. If something is poorly named (e.g. a bad resource address
>> name) we can fix it in a later release but also register an alias under
>> the old name to provide compatibility.
>>
>> I don't see how aliasing could work here. Only thing I can imagine is
>> using it in the ls -l output, such that the same attribute can appear >
>> 1 times, if it is associated with more than 1 group. I suppose a console
>> could do a similar thing, but I don't at all regard maintaining that
>> kind of compatibility in UI layout to be a requirement.
>>
>> I'm not sure how much we regard consistency in the ls -l output across
>> releases as being a requirement. I think of that as being an output
>> format for humans, not machines.
>>
>> Aliasing is an example of a reason for allowing an attribute to belong
>> to more than one group. There may be others. Perhaps as an aid to querying?
>
> I still feel strongly that we should look to real resource versioning as
> the proper solution here, though I realize there has not been a
> satisfactory resolution to this discussion.  But the longer we don't
> come to a resolution, the more (arguably questionable) tricks we have to
> pull to manage compatibility.
>

Agreed, at least re: we need to come to a resolution and that I don't
want to add further tricks. So I don't see the aliasing use case as
being a sufficient justification for allowing an attribute to be
associated with > 1 group.

The (vague) querying notion is more interesting to me as a reason for
allowing > 1 group. Really all I've described here is a form of tagging
attributes. However, separating "tags" for querying from
"attribute-group" which is specifically intended as a primary grouping
clue for management UIs is IMO better.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management model attribute groups

Brian Stansberry
On 12/10/14, 11:01 AM, Brian Stansberry wrote:

> On 12/10/14, 10:02 AM, David M. Lloyd wrote:
>> On 12/10/2014 08:21 AM, Brian Stansberry wrote:
>>> On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote:
>>>> Maybe we should also group attributes by their attribute group names instead of displaying them per natural sorting ?
>>>
>>> This is what I meant by
>>>
>>> "4) Low level management API
>>>
>>> The output of read-resource and read-resource-description is modified
>>> such that attributes are sorted by group name and then by attribute name."
>>>
>>> I used the verb "sorted" though because I have no intent of modifying
>>> the output structure by creating a level for the attribute group. That
>>> would be an incompatible change in the output format and would obscure
>>> the distinction between an attribute group and a complex attribute.
>>
>> FWIW I think this is a good distinction and a good approach.
>>
>>>> Is aliasing to be supported ?  What if I want to change the attribute group name ?
>>>>
>>>
>>> Good question.
>>>
>>> Heiko, I don't think Emmanuel is talking about users changing this. We
>>> use aliasing in other contexts as a mechanism for maintaining
>>> compatibility. If something is poorly named (e.g. a bad resource address
>>> name) we can fix it in a later release but also register an alias under
>>> the old name to provide compatibility.
>>>
>>> I don't see how aliasing could work here. Only thing I can imagine is
>>> using it in the ls -l output, such that the same attribute can appear >
>>> 1 times, if it is associated with more than 1 group. I suppose a console
>>> could do a similar thing, but I don't at all regard maintaining that
>>> kind of compatibility in UI layout to be a requirement.
>>>
>>> I'm not sure how much we regard consistency in the ls -l output across
>>> releases as being a requirement. I think of that as being an output
>>> format for humans, not machines.
>>>
>>> Aliasing is an example of a reason for allowing an attribute to belong
>>> to more than one group. There may be others. Perhaps as an aid to querying?
>>
>> I still feel strongly that we should look to real resource versioning as
>> the proper solution here, though I realize there has not been a
>> satisfactory resolution to this discussion.  But the longer we don't
>> come to a resolution, the more (arguably questionable) tricks we have to
>> pull to manage compatibility.
>>
>
> Agreed, at least re: we need to come to a resolution and that I don't
> want to add further tricks. So I don't see the aliasing use case as
> being a sufficient justification for allowing an attribute to be
> associated with > 1 group.
>

Hit send too early -- meant to say I'll try and think a lot about the
versioning thing over the holidays when I'll be away from email/chat/etc
and can actually focus on something big.

> The (vague) querying notion is more interesting to me as a reason for
> allowing > 1 group. Really all I've described here is a form of tagging
> attributes. However, separating "tags" for querying from
> "attribute-group" which is specifically intended as a primary grouping
> clue for management UIs is IMO better.
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12