9:21 a.m.
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