Management model attribute groups

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

Re: Management model attribute groups

David Lloyd-2
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 <[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"?

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.

--
- 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

Brian Stansberry
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 <[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"?
>
> 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.

--
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 Brian Stansberry
On 12/10/14, 8:29 AM, Brian Stansberry wrote:
> 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.

https://github.com/wildfly/wildfly-core/pull/391
https://issues.jboss.org/browse/WFCORE-457

> 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 Heiko Braun
https://issues.jboss.org/browse/WFCORE-458 for the read-attribute-group
bits.

On 12/10/14, 1:04 AM, Heiko Braun wrote:
> +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


--
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

jtgreene
Administrator
In reply to this post by Brian Stansberry

> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <[hidden email]> 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 <[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"?
>>
>> 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.

--
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

Brian Stansberry
On 12/10/14, 5:14 PM, Jason Greene wrote:

>
>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <[hidden email]> 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 <[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"?
>>>
>>> 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.


--
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
On 12/10/2014 05:27 PM, Brian Stansberry wrote:

> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <[hidden email]> wrote:
>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>>> 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.

Why does it make a difference?  The attribute names would be "a.b.c"
instead of just "a", but I don't see that as an impracticality.

> Withoutthat syntax, the parameter list would look much like the parameters for
> the resource's "add" operation.

Why is that a problem?  It's essentially the same thing in most cases,
isn't it?

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

Why not?

--
- 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

Brian Stansberry
In reply to this post by Brian Stansberry
On 12/10/14, 5:27 PM, Brian Stansberry wrote:

> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>
>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>>> <[hidden email]> 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
>>>>>>>>> <[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"?
>>>>
>>>> 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.
>

I gave up writing up the JIRA, as I want it to be precise and it can't
be precise enough until we have a good solution to this question. An
ugly one is:

:write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])

That's a lot more confusing and verbose than

:write-attributes(foo=123,bar.baz.zap=hello)



--
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
On 12/10/2014 05:35 PM, Brian Stansberry wrote:

> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>
>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>>>> <[hidden email]> 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
>>>>>>>>>> <[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"?
>>>>>
>>>>> 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.
>>
>
> I gave up writing up the JIRA, as I want it to be precise and it can't
> be precise enough until we have a good solution to this question. An
> ugly one is:
>
> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>
> That's a lot more confusing and verbose than
>
> :write-attributes(foo=123,bar.baz.zap=hello)

I guess I missed a beat; why can't we do the latter?  Is it because of
the way we describe operations?  IMO this operation should be on an
equal footing with adding resources and we should have a uniform means
to describe it as such.

--
- 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

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

> On 12/10/2014 05:27 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry <[hidden email]> wrote:
>>>> On 12/10/14, 11:44 AM, David M. Lloyd wrote:
>>>>> 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.
>
> Why does it make a difference?  The attribute names would be "a.b.c"
> instead of just "a", but I don't see that as an impracticality.
>

IIRC the syntax also allows list indexing, so it's not static.

>> Withoutthat syntax, the parameter list would look much like the parameters for
>> the resource's "add" operation.
>
> Why is that a problem?  It's essentially the same thing in most cases,
> isn't it?
>
>> 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.
>
> Why not?
>


--
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, 5:37 PM, David M. Lloyd wrote:

> On 12/10/2014 05:35 PM, Brian Stansberry wrote:
>> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>>
>>>>> On Dec 10, 2014, at 11:52 AM, Brian Stansberry
>>>>> <[hidden email]> 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
>>>>>>>>>>> <[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"?
>>>>>>
>>>>>> 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.
>>>
>>
>> I gave up writing up the JIRA, as I want it to be precise and it can't
>> be precise enough until we have a good solution to this question. An
>> ugly one is:
>>
>> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>>
>> That's a lot more confusing and verbose than
>>
>> :write-attributes(foo=123,bar.baz.zap=hello)
>
> I guess I missed a beat; why can't we do the latter?  Is it because of
> the way we describe operations?  IMO this operation should be on an
> equal footing with adding resources and we should have a uniform means
> to describe it as such.
>

We describe the parameters to operations, including their names, and for
all cases up to now those are easily and statically known. The CLI
validates the parameter names used in low-level ops against the description.

This can be solved by analyzing any complex attributes and outputing all
valid paths, using syntax like [] or [?] or [*] to indicate path
segments that represent elements in a list. We don't allow '.', '[' or
']' in attribute/field names, so the presence of the [ is enough to
indicate that a list element is being described; the remaining ']', '?]'
or '*]' are just to improve readability. I prefer a simple '[]'.

--
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 David Lloyd-2

On Thu, Dec 11, 2014 at 12:37 AM, David M. Lloyd <[hidden email]> wrote:
I guess I missed a beat; why can't we do the latter?  Is it because of
the way we describe operations?  IMO this operation should be on an
equal footing with adding resources and we should have a uniform means
to describe it as such.

I think what you are looking for is being addressed as part of different issue.
We had discussion about it few months back.
The proposed behavior is described here https://gist.github.com/ctomc/91055a6f4e7502dcd130
The first part about collections operations is already done the extended write/read-attribute syntax not yet.
Jira for it https://issues.jboss.org/browse/WFCORE-460

Is this what you are aiming for?
as :write-attributes operation we are talking about is different thing, just allowing us to atomically update more than
one attribute. The extended manipulation syntax would also apply to this.



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

A write-attributes op, and dealing with complex attribute paths

Brian Stansberry
In reply to this post by Brian Stansberry
This is a separate topic from the previous thread, so renaming.
Bottom-post below...

On 12/10/14, 6:02 PM, Brian Stansberry wrote:

> On 12/10/14, 5:37 PM, David M. Lloyd wrote:
>> On 12/10/2014 05:35 PM, Brian Stansberry wrote:
>>> On 12/10/14, 5:27 PM, Brian Stansberry wrote:
>>>> On 12/10/14, 5:14 PM, Jason Greene wrote:
>>>>>>> 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:
>>>>>>>>>>> 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.
>>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>
>>> I gave up writing up the JIRA, as I want it to be precise and it can't
>>> be precise enough until we have a good solution to this question. An
>>> ugly one is:
>>>
>>> :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>>>
>>> That's a lot more confusing and verbose than
>>>
>>> :write-attributes(foo=123,bar.baz.zap=hello)
>>
>> I guess I missed a beat; why can't we do the latter?  Is it because of
>> the way we describe operations?  IMO this operation should be on an
>> equal footing with adding resources and we should have a uniform means
>> to describe it as such.
>>
>
> We describe the parameters to operations, including their names, and for
> all cases up to now those are easily and statically known. The CLI
> validates the parameter names used in low-level ops against the description.
>
> This can be solved by analyzing any complex attributes and outputing all
> valid paths, using syntax like [] or [?] or [*] to indicate path
> segments that represent elements in a list. We don't allow '.', '[' or
> ']' in attribute/field names, so the presence of the [ is enough to
> indicate that a list element is being described; the remaining ']', '?]'
> or '*]' are just to improve readability. I prefer a simple '[]'.
>

IMHO my post ^^^ is wrong-headed. I don't think we should try and
describe this kind of thing this way in the operation description.

The CLI can't take an operation description listing legal values like
bar[*].baz and use it the same way it can use plain old "bar". The
string "bar[*].baz" is not valid input to send to the server; the user
has to replace the * with a number. Since the CLI can't just use the
string as is, there's not much benefit sending a bunch of text from the
server.

Fundamentally, the CLI needs to specially handle the parameter names for
the "write-attributes" op, and the value for the "name" parameter for
the "write-attribute" op:

1) There needs to be special tab completion behavior. For example, after
the user types 'bar', if they hit tab, in the write-attributes case, the
output is

. =

This reflects that the user can either provide a deeper path into the
complex attribute, or move on to specifying the value of param "bar".

In the write-attribute case, after the user types name=bar and hits tab,
the output is:

. ,

Comma instead of = to indicate they want to move on to the next param.

Similar stuff for the [ and ] chars when dealing with lists.

2) Before sending a low-level op, the CLI validates the op's param names
against the param names listed in the operation description. This
validation should understand how to validate bar[0].baz.

These two aspects of behavior could just be hard-coded into the CLI. To
be formal though, we could add a couple pieces of boolean metadata to
the parameter description:

a) one indicating that the parameter name itself can be expanded into a
deeper path. This would be used in the params to the "write-attributes" op.
b) one indicating that the parameter value can be expanded from the
formally specified legal values. This would be used with the "name"
param for the "write-attribute" op, if we ever improved its description
to properly list the legal values.

--
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: A write-attributes op, and dealing with complex attribute paths

Heiko Braun

It’s hard to see the full context of this email thread, but here are two proposals I would like to comment on:

a) write attribute groups / or writing to attribute groups?
i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})

b) nested attribute syntax
i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])


I think these are two different concerns, hence I am going to respond separately:

What’s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group?

I have similar problems with proposal b). What’s the intention behind the nested attribute syntax? A more convenient way to address complex attributes? Or does this address attributes that belong to child resources?












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

Re: A write-attributes op, and dealing with complex attribute paths

Brian Stansberry
On 12/12/14, 2:14 AM, Heiko Braun wrote:

>
> It’s hard to see the full context of this email thread, but here are two proposals I would like to comment on:
>
> a) write attribute groups / or writing to attribute groups?
> i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})
>
> b) nested attribute syntax
> i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])
>
>
> I think these are two different concerns, hence I am going to respond separately:
>
> What’s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group?
>

I don't propose to do a). The current proposal is this:

:write-attributes(attr1=5,attr2=true)

No relationship at all to attribute groups. The idea for it just evolved
from an earlier suggestion in the thread for a).

This is simply a simpler syntax for a CLI batch that has two steps

batch
:write-attribute(name=attr1,value=5)
:write-attribute(name=att2,value=true)
run-batch

The batch/run-batch is just CLI syntax for grouping in a "composite" op,
so the console could take advantage of the same thing if it wishes,
eliminating some composites. The "composite" op then is only needed if
the steps involve > 1 address, or if some step is something other than
write-attribute.

> I have similar problems with proposal b). What’s the intention behind the nested attribute syntax? A more convenient way to address complex attributes?

Yes, a more convenient way to address complex attributes.

The current proposal is not your b) though. There are two uses for
nested-attribute syntax:

:write-attribute(name=bar[1].baz,value=true)

:write-attributes(attr1=5,bar[1].baz=true)

The latter is just syntactic sugar for a 2 step composite where the 2nd
step is the former.

Or does this address attributes that belong to child resources?

No, not at all. The target of an operation is indicated by its address.

>
>
>
>
>
>
>
>
>
>
>


--
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: A write-attributes op, and dealing with complex attribute paths

Heiko Braun
Thanks for the clarification Brian.

On 12 Dec 2014, at 16:08, Brian Stansberry <[hidden email]> wrote:

On 12/12/14, 2:14 AM, Heiko Braun wrote:

It’s hard to see the full context of this email thread, but here are two proposals I would like to comment on:

a) write attribute groups / or writing to attribute groups?
i.e :write-attribute-group(name=mygroup, value={attr1=a, attr2=b})

b) nested attribute syntax
i.e. :write-attributes(attributes=[{name=foo,value=123},{name=bar.baz.zap,value=hello}])


I think these are two different concerns, hence I am going to respond separately:

What’s the intention of proposal a)? Do you want to define new attribute groups this way or do you want to write values of attributes that belong to a specific group?


I don't propose to do a). The current proposal is this:

:write-attributes(attr1=5,attr2=true)

No relationship at all to attribute groups. The idea for it just evolved from an earlier suggestion in the thread for a).

This is simply a simpler syntax for a CLI batch that has two steps

batch
:write-attribute(name=attr1,value=5)
:write-attribute(name=att2,value=true)
run-batch

The batch/run-batch is just CLI syntax for grouping in a "composite" op, so the console could take advantage of the same thing if it wishes, eliminating some composites. The "composite" op then is only needed if the steps involve > 1 address, or if some step is something other than write-attribute.

I have similar problems with proposal b). What’s the intention behind the nested attribute syntax? A more convenient way to address complex attributes?

Yes, a more convenient way to address complex attributes.

The current proposal is not your b) though. There are two uses for nested-attribute syntax:

:write-attribute(name=bar[1].baz,value=true)

:write-attributes(attr1=5,bar[1].baz=true)

The latter is just syntactic sugar for a 2 step composite where the 2nd step is the former.

Or does this address attributes that belong to child resources?

No, not at all. The target of an operation is indicated by its address.














-- 
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

Tomasz Adamski
In reply to this post by Brian Stansberry
I would like to raise once again the issue of nested attribute groups.

I started rewriting iiop subsystem so that it uses attribute groups and I think that in many cases it would be covenient and more descriptive if we are able to nest attribute groups.

There are two models related to it: subsystem xml description and management api but I believe that both of them may benefit from nested attributes.

Example:

Currently ior-settings xml tag is used to group all ior releted configuration:
<ior-settings>
   
    username_password" (...)/>
    config caller-propagation="supported" (...)/>
ior-settings>

After attribute group refactor it would currently turn to:

username_password" (...)/>
config caller-propagation="supported" (...)/>

It would be nice to be able to group them together once again. This may be achieved by adding methods to PersistentResourceXMLDescription which will make it possible to create more complex xml schema independent of attribute groups. On the other hand, what is beneficial from xml point of view may also be beneficial for management tools: if those three elements have all different groups there they will be displayed separately after sort but if we created a nested groups and do a nested sorting of them then they could be grouped together in management tools too. Moreover, all information about attribute will still be containted in its definition and subsystem creation using PersistentResourceXMLDescription will stay as simple as it is now.

Having that in mind I would suggest extending the group notion from flat to nested and create direct mapping between group parts and xml tags.

In the above example we would have:

AttributeDefinition INTEGRITY = (...).setAttributeGroup("ior-settings.as-context")(...)
AttributeDefinition AUTH_METHOD = (...).setAttributeGroup("ior-settings.sas-context")(...)
AttributeDefinition CALLER_PROPAGATION = (...).setAttributeGroup("ior-settings.transport-config")(...)

PersistentResourceXMLDescription xmlDescription = builder(IIOPResourceDefinition.INSTANCE).addAttributes(IIOPResourceDefinition.INTEGRITY,IIOPResourceDefinition.AUTH_METHOD,IIOPResourceDefinition.CALLER_PROPAGATION)(...)

This would create parser able of parsing:

xmlns="urn:jboss:domain:iiop-openjdk:1.0">
    (...)
    <ior-settings>
       
        username_password" (...)/>
        config caller-propagation="supported" (...)/>
    ior-settings>
    (...)



Problems:
How to represent the group in management api?

LIST vs STRING
:read-attribute-group(group=foo.bar) vs :read-attribute-group(group=[foo,bar])
:read-attribute-group(group=foo) vs :read-attribute-group(group=[foo])

String seem more convenient but there are some consequences of keeping a LIST (which attribute group actually is) in the form of the STRING: some parts of management client code will have to do additional work because of that
(f.e. string parsing), tab completion feature will have to hint string part by part which may be not consistent with other parts of api etc.

----- Original Message -----
From: "Brian Stansberry" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 9, 2014 9:00:21 PM
Subject: [wildfly-dev] Management model attribute groups

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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12