Management Model: Squatter Resources

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Management Model: Squatter Resources

Heiko Braun


TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions


Background:

For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.


Problem:

Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:

/subsystem=datasources/data-source=ExampleDS

In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.

In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:

/subsystem=ejb3/service=[async | remote | timer-service]

In this case each resource under /subsystem=ejb3/service has a different type and only a single instance can exist:

/service=async
/service=remote
/service=timer-service

Lacking a better alternative, I coined the term 'squatter' resources, because these resources squat a specific address slots. Squatter resources can be pre-registered or non-exisiting when the management layer is started.

In order to provide a data binding layer for the management console, we need to access the definition of a resource (:read-resource-description). With squatter resources this is basically impossible, because the existence of these types is hidden in the general API. I.e. sticking to the previous example, when querying the resource definition for the ejb3 subsystem, it pretends only single type 'service' exists, although it's actually three different 'service' types

./subsystem=ejb3:read-children-types
{
   "outcome" => "success",
   "result" => [
       [...],
       "service",
       [...]
   ]
}

Proposal:

After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources:

./subsystem=ejb3:read-children-types(include-squatters=true)
{
   "outcome" => "success",
   "result" => [
       [...],
       "service=async",
        "service=remote",
        "service=timer-service"
       [...]
   ]
}

This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition.


Thoughts and comments welcome.
If you can think of better term than 'squatter' resources, please let me know as well.

Regards, Heiko
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko W.Rupp

Am 05.08.2014 um 09:42 schrieb Heiko Braun <[hidden email]>:

> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions

I totally like this.
Even if the RHQ approach is a bit different, the change will allow us to better support
those potentially non-existing squatters.

Do the squatters have all the same attributes or does one still individually deal with them?

  Heiko


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko Braun
Not sure I understand the question. Can you elaborate on this?

On 05 Aug 2014, at 12:59, Heiko W.Rupp <[hidden email]> wrote:

Do the squatters have all the same attributes or does one still individually deal with them?


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Tomaž Cerar-2
In reply to this post by Heiko Braun
Hi,

when I first started reading I was bit alarmed you want to do something crazy thing :-)

Given that you just want to add extra option to read-children-types operation i see no harm in that.
I would just name them differently, in all our terminology this types are just non wildcard resources
if you look at the PathElement which is essentially what you are talking about.
in case that you have path element key = * you have wildcard address/resource which you use as normal
for cases were you have key=value you have static non wildcard address/resource.

so i would rather use some term in this vicinity.

--
tomaz



On Tue, Aug 5, 2014 at 9:42 AM, Heiko Braun <[hidden email]> wrote:


TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions


Background:

For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.


Problem:

Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:

/subsystem=datasources/data-source=ExampleDS

In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.

In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:

/subsystem=ejb3/service=[async | remote | timer-service]

In this case each resource under /subsystem=ejb3/service has a different type and only a single instance can exist:

/service=async
/service=remote
/service=timer-service

Lacking a better alternative, I coined the term 'squatter' resources, because these resources squat a specific address slots. Squatter resources can be pre-registered or non-exisiting when the management layer is started.

In order to provide a data binding layer for the management console, we need to access the definition of a resource (:read-resource-description). With squatter resources this is basically impossible, because the existence of these types is hidden in the general API. I.e. sticking to the previous example, when querying the resource definition for the ejb3 subsystem, it pretends only single type 'service' exists, although it's actually three different 'service' types

./subsystem=ejb3:read-children-types
{
   "outcome" => "success",
   "result" => [
       [...],
       "service",
       [...]
   ]
}

Proposal:

After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources:

./subsystem=ejb3:read-children-types(include-squatters=true)
{
   "outcome" => "success",
   "result" => [
       [...],
       "service=async",
        "service=remote",
        "service=timer-service"
       [...]
   ]
}

This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition.


Thoughts and comments welcome.
If you can think of better term than 'squatter' resources, please let me know as well.

Regards, Heiko
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

kkhan
I have used ‘specific’ vs ‘wildcard’ in the past when explaining/discussing stuff
On 5 Aug 2014, at 12:43, Tomaž Cerar <[hidden email]> wrote:

> Hi,
>
> when I first started reading I was bit alarmed you want to do something crazy thing :-)
>
> Given that you just want to add extra option to read-children-types operation i see no harm in that.
> I would just name them differently, in all our terminology this types are just non wildcard resources
> if you look at the PathElement which is essentially what you are talking about.
> in case that you have path element key = * you have wildcard address/resource which you use as normal
> for cases were you have key=value you have static non wildcard address/resource.
>
> so i would rather use some term in this vicinity.
>
> --
> tomaz
>
>
>
> On Tue, Aug 5, 2014 at 9:42 AM, Heiko Braun <[hidden email]> wrote:
>
>
> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>
>
> Background:
>
> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>
>
> Problem:
>
> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>
> /subsystem=datasources/data-source=ExampleDS
>
> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>
> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>
> /subsystem=ejb3/service=[async | remote | timer-service]
>
> In this case each resource under /subsystem=ejb3/service has a different type and only a single instance can exist:
>
> /service=async
> /service=remote
> /service=timer-service
>
> Lacking a better alternative, I coined the term 'squatter' resources, because these resources squat a specific address slots. Squatter resources can be pre-registered or non-exisiting when the management layer is started.
>
> In order to provide a data binding layer for the management console, we need to access the definition of a resource (:read-resource-description). With squatter resources this is basically impossible, because the existence of these types is hidden in the general API. I.e. sticking to the previous example, when querying the resource definition for the ejb3 subsystem, it pretends only single type 'service' exists, although it's actually three different 'service' types
>
> ./subsystem=ejb3:read-children-types
> {
>    "outcome" => "success",
>    "result" => [
>        [...],
>        "service",
>        [...]
>    ]
> }
>
> Proposal:
>
> After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources:
>
> ./subsystem=ejb3:read-children-types(include-squatters=true)
> {
>    "outcome" => "success",
>    "result" => [
>        [...],
>        "service=async",
>         "service=remote",
>         "service=timer-service"
>        [...]
>    ]
> }
>
> This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition.
>
>
> Thoughts and comments welcome.
> If you can think of better term than 'squatter' resources, please let me know as well.
>
> Regards, Heiko
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko W.Rupp
In reply to this post by Heiko Braun

Am 05.08.2014 um 13:02 schrieb Heiko Braun <[hidden email]>:

> Not sure I understand the question. Can you elaborate on this?

Will have service=async and service=timer-service
have the same attributes / operations (as the type - the part left of the '='  - is the same)?
I guess not, but would like to know anyway.

>
> On 05 Aug 2014, at 12:59, Heiko W.Rupp <[hidden email]> wrote:
>
>> Do the squatters have all the same attributes or does one still individually deal with them?
>

--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko W.Rupp
In reply to this post by kkhan

Am 05.08.2014 um 13:45 schrieb Kabir Khan <[hidden email]>:

> I have used ‘specific’ vs ‘wildcard’ in the past when explaining/discussing stuff

Aren't the "specific" ones also "singletons"; I think that would also capture the spirit.

  Heiko



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

David Lloyd-2
In reply to this post by Heiko Braun
On 08/05/2014 02:42 AM, Heiko Braun wrote:

> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>
> Background:
>
> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>
> Problem:
>
> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>
> /subsystem=datasources/data-source=ExampleDS
>
> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>
> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>
> /subsystem=ejb3/service=[async | remote | timer-service]

We've solved this a different way in the "next" management model.  We
introduce the concept of an "attribute group".  In your example we'd
perhaps have an attribute group for async, one for remote, and one for
timer-service within the root resource.

An attribute group is something like a composition resource.  They can
be optional or mandatory, and they can be named or anonymous.

A named attribute group would be separately addressable as a unit, or
can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
Also they can be arbitrarily nested.

An anonymous attribute group is just a logical grouping which is only
relevant to the server Java API itself and is invisible to the so-called
"DMR" or REST style API.  We can use these groups to retrofit existing
subsystems without breaking compatibility (this gives certain code reuse
benefits which are not important to this discussion).

This way we preserve the invariant that all attributes with a given key
have a related type (we also introduce the concept of type hierarchies
though, which mitigates this constraint in a different way, but that's
not related to this).

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Brian Stansberry
In reply to this post by Heiko W.Rupp
On 8/5/14, 8:03 AM, Heiko W.Rupp wrote:
>
> Am 05.08.2014 um 13:02 schrieb Heiko Braun <[hidden email]>:
>
>> Not sure I understand the question. Can you elaborate on this?
>
> Will have service=async and service=timer-service
> have the same attributes / operations (as the type - the part left of the '='  - is the same)?
> I guess not, but would like to know anyway.
>

They are quite different.

The issue here is how to identify "types". All address segments consist
of key/value pairs[1], and in most cases the key identifies the type and
the value is a specific instance name.

There are many cases though where a pair isn't really needed to identify
the type, and there can only be one instance. (Your 'singleton' idea for
the term to use is definitely a good candidate.) But we have to force
the address element into a pair.

In some cases we have really crappy pairs that just repeat the key,
foo=FOO. Where we could we tried to come up with some sort of common
concept to use as a key, just to make it more intuitive for people tab
completing in the CLI. That's where this 'service' key comes from. But
"common concept" != an actual type.


[1] Why key/value pairs? First, in many cases it's the right fit. But
also, requiring this allows us always to map resource addresses to JMX
ObjectNames.

>>
>> On 05 Aug 2014, at 12:59, Heiko W.Rupp <[hidden email]> wrote:
>>
>>> Do the squatters have all the same attributes or does one still individually deal with them?
>>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Brian Stansberry
In reply to this post by David Lloyd-2
On 8/5/14, 8:49 AM, David M. Lloyd wrote:

> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>
>> Background:
>>
>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>
>> Problem:
>>
>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>
>> /subsystem=datasources/data-source=ExampleDS
>>
>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>
>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>
>> /subsystem=ejb3/service=[async | remote | timer-service]
>
> We've solved this a different way in the "next" management model.  We
> introduce the concept of an "attribute group".  In your example we'd
> perhaps have an attribute group for async, one for remote, and one for
> timer-service within the root resource.
>
> An attribute group is something like a composition resource.  They can
> be optional or mandatory, and they can be named or anonymous.
>
> A named attribute group would be separately addressable as a unit, or
> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
> Also they can be arbitrarily nested.
>
> An anonymous attribute group is just a logical grouping which is only
> relevant to the server Java API itself and is invisible to the so-called
> "DMR" or REST style API.  We can use these groups to retrofit existing
> subsystems without breaking compatibility (this gives certain code reuse
> benefits which are not important to this discussion).
>
> This way we preserve the invariant that all attributes with a given key
> have a related type (we also introduce the concept of type hierarchies
> though, which mitigates this constraint in a different way, but that's
> not related to this).
>

Is there a notion of null/undefined for the attribute group itself, as
opposed to the individual attributes?

That's a conceptual distinction -- a resource doesn't exist unless it's
added.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko Braun
In reply to this post by Heiko W.Rupp





> Am 05.08.2014 um 15:03 schrieb "Heiko W.Rupp" <[hidden email]>:
>
>
>> Am 05.08.2014 um 13:02 schrieb Heiko Braun <[hidden email]>:
>>
>> Not sure I understand the question. Can you elaborate on this?
>
> Will have service=async and service=timer-service
> have the same attributes / operations (as the type - the part left of the '='  - is the same)?
> I guess not, but would like to know anyway

As i said, these are different resource types and thus have different operations and attributes.



>>
>>> On 05 Aug 2014, at 12:59, Heiko W.Rupp <[hidden email]> wrote:
>>>
>>> Do the squatters have all the same attributes or does one still individually deal with them?
>
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko Braun
In reply to this post by David Lloyd-2
But i guess attribute groups dont represent resource types. I.e they dont have operations associated, like types do.

I think your example demonstrates a different concept.




> Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" <[hidden email]>:
>
>> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>
>> Background:
>>
>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>
>> Problem:
>>
>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>
>> /subsystem=datasources/data-source=ExampleDS
>>
>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>
>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>
>> /subsystem=ejb3/service=[async | remote | timer-service]
>
> We've solved this a different way in the "next" management model.  We
> introduce the concept of an "attribute group".  In your example we'd
> perhaps have an attribute group for async, one for remote, and one for
> timer-service within the root resource.
>
> An attribute group is something like a composition resource.  They can
> be optional or mandatory, and they can be named or anonymous.
>
> A named attribute group would be separately addressable as a unit, or
> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
> Also they can be arbitrarily nested.
>
> An anonymous attribute group is just a logical grouping which is only
> relevant to the server Java API itself and is invisible to the so-called
> "DMR" or REST style API.  We can use these groups to retrofit existing
> subsystems without breaking compatibility (this gives certain code reuse
> benefits which are not important to this discussion).
>
> This way we preserve the invariant that all attributes with a given key
> have a related type (we also introduce the concept of type hierarchies
> though, which mitigates this constraint in a different way, but that's
> not related to this).
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

kkhan
In reply to this post by Heiko W.Rupp

On 5 Aug 2014, at 14:04, Heiko W.Rupp <[hidden email]> wrote:

>
> Am 05.08.2014 um 13:45 schrieb Kabir Khan <[hidden email]>:
>
>> I have used ‘specific’ vs ‘wildcard’ in the past when explaining/discussing stuff
>
> Aren't the "specific" ones also "singletons"; I think that would also capture the spirit.
To me ‘singleton’ sounds the best so far
>
>  Heiko
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

David Lloyd-2
In reply to this post by Brian Stansberry
On 08/05/2014 09:00 AM, Brian Stansberry wrote:

> On 8/5/14, 8:49 AM, David M. Lloyd wrote:
>> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>>
>>> Background:
>>>
>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>>
>>> Problem:
>>>
>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>>
>>> /subsystem=datasources/data-source=ExampleDS
>>>
>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>>
>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>>
>>> /subsystem=ejb3/service=[async | remote | timer-service]
>>
>> We've solved this a different way in the "next" management model.  We
>> introduce the concept of an "attribute group".  In your example we'd
>> perhaps have an attribute group for async, one for remote, and one for
>> timer-service within the root resource.
>>
>> An attribute group is something like a composition resource.  They can
>> be optional or mandatory, and they can be named or anonymous.
>>
>> A named attribute group would be separately addressable as a unit, or
>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
>> Also they can be arbitrarily nested.
>>
>> An anonymous attribute group is just a logical grouping which is only
>> relevant to the server Java API itself and is invisible to the so-called
>> "DMR" or REST style API.  We can use these groups to retrofit existing
>> subsystems without breaking compatibility (this gives certain code reuse
>> benefits which are not important to this discussion).
>>
>> This way we preserve the invariant that all attributes with a given key
>> have a related type (we also introduce the concept of type hierarchies
>> though, which mitigates this constraint in a different way, but that's
>> not related to this).
>>
>
> Is there a notion of null/undefined for the attribute group itself, as
> opposed to the individual attributes?

Yes, but only for "optional" attribute groups.  IOW the resource author
can decide if that's appropriate or not.

I have not yet completely worked out how manipulation operations would
look for this.  I think it may be closely tied in to what we do for
so-called "complex" attributes though.

> That's a conceptual distinction -- a resource doesn't exist unless it's
> added.

Yes, it's a distinct concept.  However (at least for the given example)
I think that an attribute group is a better fit.  The problem with
"squatters" is that they don't really have a common API, and yet they
aren't really independent - it's just a way of addressing the
composition of a parent resource.  You can't really use the mechanism
(as described) to plug in extensions.  So it's yet another logical model
for resources we have to introduce.  I think in terms of the logical
model of management resources themselves, we're close to the breaking
point in a couple ways, even if only due to the way we handle
subsystems, inter-resource linkage etc., where it's going to be
difficult to come up with any kind of internally consistent management
API unification concept if we make it any more complex.

The problem that Heiko is trying to solve, I think, is that there's a
tension here.  Large resources aren't, by themselves, inherently "bad",
in terms of the system and its implementation.  However once you
introduce human interfaces like CLI and console, it becomes difficult
for people to manage due to just the overall spamming of management
information.  So there's a tension between having complete and robust
resources, and making them consumable by normal human beings.  I
definitely agree with this, and I think that trying to solve this is a
very reasonable and logical step (and those who know me should know that
"reasonable" is about the highest compliment that I give).

But if we do solve this then it has to be done in a way that we can
adapt to, or else we may cross the line from "the new management is a
pretty big effort" to "the new management model is dead".  And I think
that if the new management model can't accommodate a new abstraction in
a logically consistent way, then nothing else will be able to either.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

kkhan
In reply to this post by Heiko W.Rupp

On 5 Aug 2014, at 14:03, Heiko W.Rupp <[hidden email]> wrote:

>
> Am 05.08.2014 um 13:02 schrieb Heiko Braun <[hidden email]>:
>
>> Not sure I understand the question. Can you elaborate on this?
>
> Will have service=async and service=timer-service
> have the same attributes / operations (as the type - the part left of the '='  - is the same)?
> I guess not, but would like to know anyway.
Not necessarily
If the resource registration is done against service=*, it will be the same.
If there is a resource registration for service=async, and one for service=timer-service they can be different.


>
>>
>> On 05 Aug 2014, at 12:59, Heiko W.Rupp <[hidden email]> wrote:
>>
>>> Do the squatters have all the same attributes or does one still individually deal with them?
>>
>
> --
> Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
> Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
> Handelsregister: Amtsgericht München HRB 153243
> Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

David Lloyd-2
In reply to this post by Heiko Braun
Well, you can't really use "resource types" as part of the definition
(i.e. justification) of what a resource type is, else nothing will ever
meet that definition. :-)

But in any event, if it is important (and logical) to do so, I think we
could easily extend operations to be "scoped" to an attribute group
without really flexing the logical model very much.  The entire point of
attribute groups is pretty much exactly what your use case is.

I don't want to marginalize your idea - it's a good idea - I just don't
think I can accommodate it well in the new management model; if I did,
it would end up being exactly like attribute groups anyway (but with
distinct addresses).  But then making them be required would be impossible.

On 08/05/2014 09:15 AM, Heiko Braun wrote:

> But i guess attribute groups dont represent resource types. I.e they dont have operations associated, like types do.
>
> I think your example demonstrates a different concept.
>> Am 05.08.2014 um 15:49 schrieb "David M. Lloyd" <[hidden email]>:
>>
>>> On 08/05/2014 02:42 AM, Heiko Braun wrote:
>>> TL;DR:  A proposal for improving parts of the management API that deal with static resource definitions
>>>
>>> Background:
>>>
>>> For future Wildfly versions we plan to re-architect the management console to make better use the existing meta data. The goal is to provide a data binding layer that automates much of the retrieval and update of the configuration and runtime data. To achieve this goal, we need to remove some of the roadblocks that prevent further automation. This is the first of a series of posts that explains some of the challenges we facing and a proposal to improve the situation.
>>>
>>> Problem:
>>>
>>> Typically we deal with resources that addressable through a key value pair, where the key of the tuple depicts the type of the resource and the value the name or identify of a specific resource instance, i.e.:
>>>
>>> /subsystem=datasources/data-source=ExampleDS
>>>
>>> In this case 'ExampleDS' is the name of a resource of type 'data-source'. The type is associated with a specific resource definition, that's typically retrieved through the :read-resource-description operation. In the following sections I am going to refer to these resource as 'regular' resources.
>>>
>>> In some situations, it seems more feasible (and valid) to construct a model representation without instance names, i.e.:
>>>
>>> /subsystem=ejb3/service=[async | remote | timer-service]
>>
>> We've solved this a different way in the "next" management model.  We
>> introduce the concept of an "attribute group".  In your example we'd
>> perhaps have an attribute group for async, one for remote, and one for
>> timer-service within the root resource.
>>
>> An attribute group is something like a composition resource.  They can
>> be optional or mandatory, and they can be named or anonymous.
>>
>> A named attribute group would be separately addressable as a unit, or
>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
>> Also they can be arbitrarily nested.
>>
>> An anonymous attribute group is just a logical grouping which is only
>> relevant to the server Java API itself and is invisible to the so-called
>> "DMR" or REST style API.  We can use these groups to retrofit existing
>> subsystems without breaking compatibility (this gives certain code reuse
>> benefits which are not important to this discussion).
>>
>> This way we preserve the invariant that all attributes with a given key
>> have a related type (we also introduce the concept of type hierarchies
>> though, which mitigates this constraint in a different way, but that's
>> not related to this).
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Heiko W.Rupp
In reply to this post by David Lloyd-2

Am 05.08.2014 um 15:49 schrieb David M. Lloyd <[hidden email]>:
>
> A named attribute group would be separately addressable as a unit, or
> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
> Also they can be arbitrarily nested.

The latter scares me, as its representation in UIs can become quite
problematic.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Tomaž Cerar-2

On Tue, Aug 5, 2014 at 4:26 PM, Heiko W.Rupp <[hidden email]> wrote:
The latter scares me, as its representation in UIs can become quite
problematic.


How so? this is the easiest thing to represent in gui, just imagine it as
<fieldset> holder in html form...

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

David Lloyd-2
In reply to this post by Heiko W.Rupp
On 08/05/2014 09:26 AM, Heiko W.Rupp wrote:
>
> Am 05.08.2014 um 15:49 schrieb David M. Lloyd <[hidden email]>:
>>
>> A named attribute group would be separately addressable as a unit, or
>> can be accessed using a qualifier syntax e.g. "thegroup.theattribute".
>> Also they can be arbitrarily nested.
>
> The latter scares me, as its representation in UIs can become quite
> problematic.

Well look at it this way - it's already problematic ;-)  As with all
things, we will rely on good sense and moderation.

One can also reason that the farther you nest, the less important the
grouping becomes; after one or two levels of nesting, if such a resource
ever even comes in to being, the UI hint could simply be "sort by group"
and otherwise treat it as flat, which is no worse than the status quo
today (and arguably slightly better).

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management Model: Squatter Resources

Brian Stansberry
In reply to this post by Heiko Braun
On 8/5/14, 2:42 AM, Heiko Braun wrote:
>

> Proposal:
>
> After a chat with Brian yesterday, we are proposing a new request parameter to the :read-children-types operations, that augments the result to reveal the existence of squatter resources:
>
> ./subsystem=ejb3:read-children-types(include-squatters=true)
> {
>     "outcome" => "success",
>     "result" => [
>         [...],
>         "service=async",
> "service=remote",
> "service=timer-service"
>         [...]
>     ]
> }
>
> This works in a backwards compatible way and allows us to identify squatter resources and get to their resource definition.
>

We also have form of subtyping that's something we should explore as we
sort this. We allow a "squatter" resource description to override a
non-squatter definition. When it does this it can add attributes or
child types. The use case this was added for is where different
implementations of the service underlying a resource are possible and we
register the subtype when we install the service and learn what it supports.

For example, start the server with the ExampleDS *disabled* and read the
resource description tree for the datasources subsystem:

[standalone@localhost:9990 subsystem=datasources]
:read-resource-description(recursive=true)
{
     ....
     "children" => {
       ...
       "data-source" => {
         "description" => "A JDBC data-source configuration",
         "model-description" => {
           "*" => {...}
         }
       }
     }
}

But once you enable the datasource, another child description is
registered, for "ExampleDS":

standalone@localhost:9990 subsystem=datasources]
:read-resource-description(recursive=true)
{
     ....
     "children" => {
       ...
       "data-source" => {
         "description" => "A JDBC data-source configuration",
         "model-description" => {
           "ExampleDS" => {...},
           "*" => {...}
         }
       }
     }
}

The ExampleDS registration includes statistics attributes provided by
the underlying datasource.

So, how should we clarify this? Does
:read-children-types(include-squatters=true) include
"datasource=ExampleDS" in the result? How do we disambiguate this
"subtype" case from the "singleton" case?

I'll think about this a bit. One vague thought I have is the
:read-resource-description output is a bit too terse if you don't add
recursive=true. It's structure really assumes the non-squatter case:

[standalone@localhost:9990 subsystem=datasources] :read-resource-description
{
   "outcome" => "success",
   "result" => {
     "description" => "The data-sources subsystem, used to declare JDBC
data-sources",
     "attributes" => {...}},
     "operations" => undefined,
     "notifications" => undefined,
     "children" => {
       "jdbc-driver" => {
         "description" => "Service that make a JDBC driver available for
use in the runtime",
         "model-description" => undefined
       },
       "xa-data-source" => {
         "description" => "A JDBC XA data-source configuration",
         "model-description" => undefined
       },
       "data-source" => {
         "description" => "A JDBC data-source configuration",
         "model-description" => undefined
       }
     }
   }
}

It might be ok to just expand that '"model-description" => undefined'
part with a bit more data. It's a change in the output for an existing
op, which could be a compatibility issue, but why would a client care
about that? The existing '"model-description" => undefined' is just
useless noise that a client wouldn't process anyway.





--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123