[wildfly-dev] Management Model: Squatter Resources

Heiko Braun hbraun at redhat.com
Thu Oct 30 12:14:43 EDT 2014


Thanks for the explanation Brian. 

On 30 Oct 2014, at 17:07, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> There's a separate branch of this thread that looks to be getting into 
> discussing use cases for polymorphism, so here I'll focus on details a bit.
> 
> Right now our types are tied to addresses. The address defines the type, 
> and is used to find the description of the type. This is even true with 
> complex attributes, just with a slightly different mechanism.
> 
> To get away from having the address define the type, we would need some 
> other mechanism for declaring a type. In a hangout today, we 
> brainstormed about using special attributes[1] in any complex ModelNode 
> (i.e. any resource or a complex attribute of OBJECT type).
> 
> We'd need some clear mechanism for resolving type definitions based on 
> the data in those special attributes.
> 
> The description of the parent would have to declare what the valid types 
> are, in some combination with what the valid addresses are. That would 
> allow tooling like the console to guide the user when creating new items 
> or radically changing existing ones.
> 
> For something like the CLI it gets more cumbersome, as our UX (which I 
> like a lot) is based on tab completion. Tab completion could still 
> suggest a type, but the user's choice would no longer get recorded in 
> the current input.
> 
> This is quite a bit more flexible than the current approach, but also a 
> fair bit more cumbersome for the many cases where there's no need for 
> polymorphism, so the use case discussion is important.
> 
> 
> [1] We discussed using ".xxx" e.g. ".type" and ".namespace", with 
> attributes whose names begin with the "." prefix becoming reserved. The 
> '.' is kind of nice because it's intuitively like a hidden file on a 
> filesystem, and if we use dot syntax to separate between levels in a 
> complex attribute or between an attribute group and an item, this case 
> fits in.
> 
>> This means that user interface frameworks (for example) could know that
>> there is only one possible sub-resource address, say "service=ha-policy"
>> (to use Heiko's original naming example mixed with Jeff's practical
>> example).  Then it only has to make a decision as to how to render the
>> resource, rather than having to analyze the model to know that, of the
>> six possible children for "ha-policy", only one can ever be present.
>> 
>> On 10/30/2014 09:06 AM, Jason Greene wrote:
>>> Is it really polymorphism though if you do not share attributes or operations?
>>> 
>>> It sounds like these are all distinct types just sharing the same portion of an address.
>>> 
>>> The primary justification for this modeling approach seems to be:
>>> 
>>> 1) Avoid the user having to assign a name
>>> 2) Enforce a single occurrence of a “type”
>>> 
>>> 
>>>> On Oct 30, 2014, at 8:01 AM, David M. Lloyd <david.lloyd at redhat.com> 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
>>>> _______________________________________________
>>>> 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
>>> 
>> 
> 
> 
> -- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141030/91384920/attachment-0001.html 


More information about the wildfly-dev mailing list