[wildfly-dev] Management model attribute groups

Tomasz Adamski tadamski at redhat.com
Wed Feb 4 14:42:56 EST 2015


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" <brian.stansberry at redhat.com>
To: wildfly-dev at lists.jboss.org
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
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev


More information about the wildfly-dev mailing list