6:07 p.m.
Paul Ferraro created WFLY-6610:
----------------------------------
Summary: Default singleton policy capability needs distinct name
Key: WFLY-6610
URL: https://issues.jboss.org/browse/WFLY-6610
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 10.1.0.Final
Currently, the "org.wildfly.clustering.singleton.policy" capability name is used
by 2 capabilities:
1. The default singleton policy, using the static name
2. A named singleton policy, using a dynamic name
Even though this works, it's not future-proof, as determined by a chat session from
today:
{noformat}
Paul Ferraro·15:11
@BrianStansberry question - is it valid for a capability to be both static and dynamic?
@BrianStansberry e.g. I have 2 resources, one registers a capability using a static name,
the other resource registers a capability using the same name, but dynamic
@BrianStansberry it works fine - but it occurs to me, when completing my capability.adoc,
that the DYNAMIC field is intended to be true or false - not both
@BrianStansberry I could certainly use a different name for the static variant, but
I'm wondering if that is really necessary
Brian Stansberry·15:17
@PaulFerraro the intent is they have different names
basically because for a dynamic capability the way you learn its contract is by looking up
the static part of the name
I suppose if the static and dynamic had the same contract except for that one piece of
data it could be ok
but it sounds like something that some day would bite us in the rear
Paul Ferraro·15:18
@BrianStansberry an example of this is the SingletonPolicy capability
@BrianStansberry there are named policies (i.e. dynamic), and there is the default policy,
which references a named policy, but registers itself using the same name (but is static)
Brian Stansberry·15:20
hmm, yeah i can see the advantage of just using the static name
Paul Ferraro·15:20
so, a dependency on org.wildfly.clustering.singleton.policy gives you the default policy,
but a dependency on so, a dependency on org.wildfly.clustering.singleton.policy.foo gives
you the foo policy
Brian Stansberry·15:21
is org.wildfly.clustering.singleton.default-policy better?
I'd need to poke a bit to see if I can identify any real problems
I mean the registry info could just say (in template.adoc) DYNAMIC: true | false | both
or something
Paul Ferraro·15:22Hide card
I used "both", https://github.com/wildfly/wildfly-capabilities/pull/4
Add missing capability description for singleton policy. by pferraro · Pull Request #4 ·
wildfly/wildfly-capabilities
github.com
wildfly-capabilities - Registry of capabilities accessible via the management layer of a
WildFly Core base server
Brian Stansberry·15:22
the capability names are just string so the dynamic business is just string concatenation
hmm, maybe it would be a problem with the "possible" capability thing
Paul Ferraro·15:23
"possible"?
what is that?
Brian Stansberry·15:24
caps are declared in the ResourceDefintion. so when the RD is used to create a
ManagementResourceRegistration, the cap info is associated with the MRR
and is part of the resource def metadata
but, for a typical MRR there is no dynamic part
the point of all this is tools that are trying to help a user create a config can see
which addresses could provide the cap if a resource was added
i.e. what caps are "possible" given the set of extensions that are available
but your case becomes ambiguous
maybe that's not a big problem; it's kind of a question of data representation
Brian Stansberry goes to look how it's displayed now
Brian Stansberry·15:29
ok, good so far; it's a list not a map keyed on the static cap name:
[standalone@embedded socket-binding=management-http] :read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "Configuration information for a
socket.",
"capabilities" => [{
"name" => "org.wildfly.network.socket-binding",
"dynamic" => true
}],
Show more
Alexey Loubyansky joined the room
Brian Stansberry·15:30
@ctomc @HaraldPehl I'm curious what your thoughts are on ^^^ (tomorrow is fine)
Paul Ferraro·15:33
@BrianStansberry Here are the resource descriptions containing the singleton policy
capability:
[standalone@localhost:9990 /] /subsystem=singleton:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "The configuration of the singleton
subsystem",
"capabilities" => [{
"name" => "org.wildfly.clustering.singleton.policy",
"dynamic" => false
}],
"attributes" => {"default" => {
"type" => STRING,
"description" => "The default singleton policy",
"expressions-allowed" => false,
"nillable" => false,
"capability-reference" =>
"org.wildfly.clustering.singleton.policy",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "resource-services"
}},
"operations" => undefined,
"notifications" => undefined,
"children" => {"singleton-policy" => {
"description" => "A singleton policy",
"model-description" => undefined
}}
}
}
[standalone@localhost:9990 /]
/subsystem=singleton/singleton-policy=default:read-resource-description
{
"outcome" => "success",
"result" => {
"description" => "A singleton policy",
"capabilities" => [{
"name" => "org.wildfly.clustering.singleton.policy",
"dynamic" => true
}],
"attributes" => {
"cache" => {
"type" => STRING,
"description" => "The cache backing the singleton
policy's singleton service",
"expressions-allowed" => true,
"nillable" => true,
"default" => "default",
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"cache-container" => {
"type" => STRING,
"description" => "The cache container backing the
singleton policy's singleton service",
"expressions-allowed" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
"quorum" => {
"type" => INT,
"description" => "The minimum number of nodes required
before this singleton service will start",
"expressions-allowed" => true,
"nillable" => true,
"default" => 1,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
}
},
"operations" => undefined,
"notifications" => undefined,
"children" => {"election-policy" => {
"description" => "The election policy of this singleton
policy",
"model-description" => undefined
}}
}
}
Show more
Kabir Khan joined the room
Brian Stansberry·15:34
@PaulFerraro ok, so there it's not even the same MRR registering both variants, so
list vs map doesn't matter
I think @HaraldPehl 's input is important as he's the one who'd need to deal
with this situation
the fact that the same string can have two different meanings
it may not be a big deal for what he's doing now though
which is probably focused on giving people the valid values for attributes
and those are always for dynamic caps
Harald Pehl·15:45
@BrianStansberry For me it's important to get the possible resources for an attribute
which declares a "capability-reference" in its metadata
For instance the "profile" attribute in
"/server-group=*:read-resource-description" has a
"capability-reference" => "org.wildfly.domain.profile"
So I need a way to resolve this reference to a list of resource names which the admin can
select from
Brian Stansberry·15:50
@HaraldPehl thanks. that confirms what I thought; for right now you need to find out
dynamic capabilities
I think the tricky thing for you would be if the string
"org.wildfly.domain.profile" appeared in two different forms, one dynamic (the
one you want) and one static (irrelevant to you)
you'd have to dig a bit deeper to make sure you were looking at the right one
@BrianStansberry I think that is addressed by @ctomc PR:
https://github.com/wildfly/wildfly-core/pull/1554
WFCORE-1540 Expose capability registry via mgmt api by ctomc · Pull Request #1554 ·
wildfly/wildfly-core
github.com
wildfly-core - The core runtime that is used by the Wildfly application server
Harald Pehl·15:53
It introduces some mgmt ops to query capabilities
Harald Pehl·15:54
1. /core-service=capability-registry:read-resource which returns a list of
possible capabilities
2. /core-service=capability-registry:get-provider-points(name=org.wildfly.domain.profile)
Harald Pehl·15:56
which returns the address for a given capability
Brian Stansberry·15:56
@HaraldPehl with what @PaulFerraro is proposing, you'd probably need a 2nd param for
your #2
and probably some more parsing of the result of your #1 to get the particular data you
want
"probably" as I'm just guessing what you do with #1
Harald Pehl·15:58
I use #1 to bootstrap a registry of all known capabilities when the console starts
Brian Stansberry·15:58
does that registry include whether the cap is dynamic?
Harald Pehl·15:58
and #2 if I cannot find a capability in that registry
yes
Brian Stansberry·15:59
is the name the registry key?
Harald Pehl·16:00
yes its actually a Map<String, CapabilityInfo> with the capability name as key and
some info about that cap as value (including dynamic)
Brian Stansberry·16:01
yeah, so you need some kind of custom type as the key, or a List<CapabilityInfo> as
the value
tbh @PaulFerraro doing this sounds like a likely bug nest
Harald, I should have said "you *would* need..." -- you don't now
Paul Ferraro·16:02
@BrianStansberry ok - I'll give the static capabilities a separate name
Kabir Khan joined the room
Paul Ferraro·16:03
not a huge deal - just one more capability name to keep track of
Brian Stansberry·16:04
yeah, it's a good thought though. perhaps it will be easier for users anyway, since 2
names for two things may require less brainpower to understand
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)