On 12/9/14, 4:41 PM, Jason Greene wrote: 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. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

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

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 :

On 12/10/14, 3:59 AM, Emmanuel Hugonnet wrote: 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. 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? -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat

On 12/10/14, 10:02 AM, David M. Lloyd wrote: 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

On Tue, Dec 9, 2014 at 9:00 PM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: 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

On Wed, Dec 10, 2014 at 3:45 PM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: 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.

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 12/10/2014 09:52 AM, Brian Stansberry wrote: 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

Forgot to hit "reply to list" on this one. On 12/10/2014 10:30 AM, Brian Stansberry wrote: 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

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

On 12/10/2014 05:27 PM, Brian Stansberry wrote: 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. Why is that a problem? It's essentially the same thing in most cases, isn't it? Why not? -- - DML

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

On 12/10/14, 5:37 PM, David M. Lloyd wrote: 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

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?

Thanks for the clarification Brian.

On Wed, Dec 10, 2014 at 4:52 PM, Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: 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 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(a)redhat.com&gt; To: wildfly-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev