Details
-
Bug
-
Resolution: Done
-
Major
-
10.0.0.Final
-
None
Description
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:
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