[wildfly-dev] Management Model: Squatter Resources
Brian Stansberry
brian.stansberry at redhat.com
Thu Oct 30 12:29:10 EDT 2014
On 10/30/14, 11:07 AM, Brian Stansberry wrote:
> On 10/30/14, 10:23 AM, David M. Lloyd wrote:
>> The main advantage of polymorphism (which is really just a way of saying
>> "decoupling model location from node type") is (perhaps obviously) that
>> you can use the same model location for more than one type.
>>
>
> 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 may be less of an issue than I thought. If polymorphism is allowed,
the operation sent to the server will need to identify the type too,
presumably as a param. So that tab completion data will get recorded in
the input, like all the current cases. The special behavior here is when
polymorphism is allowed, the initial tab completion will have to only
allow choices that define the intended type. Once that is known, the
rest proceeds as it does now.
> 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
>>>
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list