[jboss-jira] [JBoss JIRA] (WFLY-10339) Broadcast/discovery-group resources have ambiguous requirement specs

[Paul Ferraro (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-10339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639792#comment-13639792 ] 

Paul Ferraro edited comment on WFLY-10339 at 9/27/18 6:24 PM:
--------------------------------------------------------------

[~jmesnil] 
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}

I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.

AIUI, the complexity for provisioning is two-fold:

# The attribute that toggles whether a JGroups-supplied capability is required is not the same attribute that determines the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.

We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined.  However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.


was (Author: pferraro):
[~jmesnil] 
{quote}Capabilities and requirements based on attributes should be sufficient:
* if socket-binding is defined, it requires a socket-binding capability
* if jgroups-xxx attribute is defined, it requires a JGroups capability
etc.
{quote}

I don't think this accurately describes the complexity of the feature requirement specs for this resource.
Rather, the current feature specification logic is:
* When the jgroups-cluster attribute is defined:
** If the jgroups-channel attribute is defined, establish a requirement for a JGroups subsystem-supplied capability with a dynamic name based on its value.
** If the jgroups-channel is undefined, establish a requirement for the default JGroups subsystem-supplied capability with a static name.
* Otherwise, establish a requirement for a socket-binding based on the value of the socket-binding attribute.

AIUI, the complexity for provisioning is two-fold:

# The attribute that toggles whether a JGroups supplied capability is needed is not the same attribute that supplies the name of the requirement
# When the jgroups-cluster attribute is defined, the jgroups-channel attribute records a requirement for one capability when defined, and another when undefined.

We have solved problem #2 in other subsystems with clustering requirements by always requiring a given default clustering capability, and only require the corresponding named capability when the attribute is defined.  However, we cannot apply the same solution here since this would establish an unnecessary clustering requirement in the event that broadcast/discovery-group was instead configured to use a socket-binding.

> Broadcast/discovery-group resources have ambiguous requirement specs
> --------------------------------------------------------------------
>
>                 Key: WFLY-10339
>                 URL: https://issues.jboss.org/browse/WFLY-10339
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 12.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: ehsavoie Hugonnet
>
> Currently, the broadcast/discovery-group resources have messy requirement specs, as the capabilities that they require are dependent whether or not the jgroups-cluster attribute is defined.
> I suggest splitting these resources into 2:
> {code}/subsystem=messaging-activemq/server=*/jgroups-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/jgroups-discovery-group=*{code}
> which requires clustering capabilities
> and
> {code}/subsystem=messaging-activemq/server=*/socket-broadcast-group=*{code}
> {code}/subsystem=messaging-activemq/server=*/socket-discovery-group=*{code}
> which requires a socket-binding capability.
> This results in clearer requirement specs - which helps simplify the introspection of this subsystem for provisioning purposes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)