[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