Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-6610

Default singleton policy capability needs distinct name

    Details

      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
      

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                pferraro Paul Ferraro
                Reporter:
                pferraro Paul Ferraro
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: