[wildfly-dev] Management Model: Squatter Resources

David M. Lloyd david.lloyd at redhat.com
Thu Oct 30 09:58:27 EDT 2014


Using schema-ish things like min/max was probably a bad idea on my part. 
  After trying to model XML schema in various ways for various reasons 
over the years, I know now that the simpler our rules are, the easier it 
will be to implement a cohesive and useful UX.

IMO any currently unused and un-useful constructs like this that are 
hanging around probably need to be pruned, before someone actually uses 
them and makes everyone's live more difficult. :-)

On 10/30/2014 08:44 AM, Brian Stansberry wrote:
> No, we don't. That currently would have to be handled in a custom way by
> the OSH that does the add for any of the children.
>
> There are some bits and pieces in the metadata that can help with doing
> some sort of automated validation (i.e. a currently basically unused
> max/min child count thing) but I don't think what's there is sufficient.
>
> The fact the metadata isn't there means a client like the console
> couldn't enforce the constraint server side, for a better UX.
>
> On 10/30/14, 8:08 AM, David M. Lloyd wrote:
>> I mean, a single child where there can be many possible types for that
>> child.
>>
>> On 10/30/2014 08:01 AM, David M. Lloyd wrote:
>>> I think that polymorphism is a new use case for 'squatters'.  I wonder
>>> if we have any existing code which enforces single children?
>>>
>>> On 10/30/2014 05:40 AM, Jeff Mesnil wrote:
>>>> I’m integrating HornetQ 2.5 in WildFly and I have a new use case for resources that is related to singleton/squatter resources.
>>>>
>>>> In HornetQ 2.5 they have completely rewritten the HA configuration. Basically, a server can be configured as live-only, replicated (master, slave, or colocated) or using shared-store (again as a master, slave or colocated).
>>>>
>>>> To represent this in the management model, I have added several resources under hornetq-server:
>>>>
>>>> /subsystem=messaging/
>>>>       hornetq-server=*/
>>>>         ha-policy=live-only
>>>>         ha-policy=replicated-master
>>>>         ha-policy=replicated-slave
>>>>         ha-policy=replicated-colocated
>>>>         ha-policy=shared-store-master
>>>>         ha-policy=shared-store-slave
>>>>         ha-policy=shared-store-colocated
>>>>
>>>> I have constraints for this ha-policy resource:
>>>>       * There can at most one child for this type of resource (no child means no HA). This is enforces during the MODEL stage.
>>>>       * The child can only be named using one of the 7 values above (i.e. there is no resource definition for ha-policy=*, using any other name would fail)
>>>>
>>>> Each ha-policy definition has a different set of attributes. Using an attribute group to represent the HA policy does not seem a good fit as some of them have subresources too.
>>>>
>>>> I wonder if that representation fits with our roadmap and whether it can be considered as a singleton (as there can only be one resource of that type among). I have the additional constraints of having only one chile for that type that is not covered by your proposal though.
>>>>
>>>> I especially wonder how the console (and to a lesser extent the cli) can deal with this resource.
>>>>
>>>> Heiko, is it something that would make sense for the console based on this resource description:
>>>>
>>>> [standalone at localhost:9990 hornetq-server=default] ./ha-policy=*:read-resource-description(recursive-depth=1)
>>>> {
>>>>         "outcome" => "success",
>>>>         "result" => [
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "replication-colocated")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "replication-master")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "shared-store-slave")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "live-only")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "shared-store-master")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "replication-slave")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             },
>>>>             {
>>>>                 "address" => [
>>>>                     ("subsystem" => "messaging"),
>>>>                     ("hornetq-server" => "default"),
>>>>                     ("ha-policy" => "shared-store-colocated")
>>>>                 ],
>>>>                 "outcome" => "success",
>>>>                 "result" => {
>>>>                     ...
>>>>                 }
>>>>             }
>>>>         ]
>>>> }
>>>>
>>>> jeff
>>>>
>>>
>>
>
>

-- 
- DML


More information about the wildfly-dev mailing list