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

Wow I am error-prone in the morning! "1:1 address to name relationship” -> 1:1 address to description relationship "/subsystem=messaging=*:read-resource-definition” -> subsystem=messaging=*:read-resource-description > On Oct 30, 2014, at 9:12 AM, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > > It sounds like in this case min/max is unnecessary because of the 1:1 address to name relationship. I think Jeff’s case is easily solved by returning fully qualified address based resource definitions. For example, if you do: > > /subsystem=messaging=*:read-resource-definition > > If the result contained nested N sets of resource definitions, as previously discussed, it’s all pretty straight forward. > > >> On Oct 30, 2014, at 9:00 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: >> >> I'm not so sure that bad idea was yours. >> >> But +1 on getting rid of the existing min/max thing. >> >> On 10/30/14, 8:58 AM, David M. Lloyd wrote: >>> 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 >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat