Default singleton policy capability needs distinct name

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