[wildfly-dev] Management Model: Squatter Resources
Jason Greene
jason.greene at redhat.com
Thu Oct 30 11:30:19 EDT 2014
Ah yes I missed that. I’ll say more in my reply to David.
> On Oct 30, 2014, at 10:16 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>
> I shouldn't have mentioned min/max, as my only point was that it was a crusty thing out there that doesn't really address the problem.
>
> In this case, yes, there could be a 1:1 address to name relationship, but there is nothing in our metadata that describes that only one of those addresses can legally exist in a given tree.
>
> We have an "alternatives" description for the requirement for a choice amongst attributes, but nothing like that for resources.
>
> On 10/30/14, 9:15 AM, Jason Greene wrote:
>> 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 at redhat.com> 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 at redhat.com> 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 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at 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
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
More information about the wildfly-dev
mailing list