Re: [wildfly-dev] Management Model: Squatter Resources

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