While this is addressed mainly to the Elytron team, it seems like we would appreciate opinions from other colleagues since we are basically stuck discussing possible ways to resolve https://issues.jboss.org/browse/WFCORE-3596 The description in the jira is pretty brief assuming people know what that is about, since it's been raised before multiple times. Here is what it is about fundamentally. If a configuration model (of a subsystem or any other component) includes a list of configurable units (let's assume XML elements for simplicity) that don't have any identity (unique id/name/path/etc) this is a big problem for supporting patching and version updates preserving user configuration changes. Or simply customizing the default config model using a tool. By a big problem I mean it's simply not going to work reliably. As a simple exercise that demonstrates the issue, imagine you have two configs each of which includes a list of these configurable units that have no identity. Now try to identify the difference between the two lists. Or merge them with one overwriting the other. Basically components w/o an identity can not be manipulated. You can only add them but not modify or even remove (unless their index in the list is a constant value of course). I don't think I've seen any issue of this kind in our (WF/EAP) configs except for the Elytron's permission-mapping's. (If somebody knows such components please let me know). If I misunderstand the Elytron config model or approaching this from a wrong angle, please let me know. Question for the Elytron team: is the problem I am describing clear? Do you admit it as a problem? Thanks, Alexey

A solution to part of the problem mentioned in WFCORE-3596 that was discussed is to introduce the concept of named permission sets. In particular, instead of having a permission-mapping reference permissions, it would instead reference named permission-sets. This would allow the provisioning tool to be able to add/remove permissions to/from a default permission-set based on the presence/absence of a specific subsystem when generating the default configuration. However, as Alexey pointed out, this doesn't solve the problem of knowing which permission-mapping a permission-set should be added to when attempting to preserve user configuration changes for patching, version updates, etc. Thanks, Farah On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < alexey.loubyansky(a)redhat.com&gt; wrote: > While this is addressed mainly to the Elytron team, it seems like we > would appreciate opinions from other colleagues since we are basically > stuck discussing possible ways to resolve > https://issues.jboss.org/browse/WFCORE-3596 > > The description in the jira is pretty brief assuming people know what > that is about, since it's been raised before multiple times. Here is what > it is about fundamentally. > > If a configuration model (of a subsystem or any other component) includes > a list of configurable units (let's assume XML elements for simplicity) > that don't have any identity (unique id/name/path/etc) this is a big > problem for supporting patching and version updates preserving user > configuration changes. Or simply customizing the default config model using > a tool. By a big problem I mean it's simply not going to work reliably. > > As a simple exercise that demonstrates the issue, imagine you have two > configs each of which includes a list of these configurable units that have > no identity. Now try to identify the difference between the two lists. Or > merge them with one overwriting the other. Basically components w/o an > identity can not be manipulated. You can only add them but not modify or > even remove (unless their index in the list is a constant value of course). > > I don't think I've seen any issue of this kind in our (WF/EAP) configs > except for the Elytron's permission-mapping's. (If somebody knows such > components please let me know). > If I misunderstand the Elytron config model or approaching this from a > wrong angle, please let me know. > > Question for the Elytron team: is the problem I am describing clear? Do > you admit it as a problem? > > Thanks, > Alexey >

On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com&gt; wrote: > A solution to part of the problem mentioned in WFCORE-3596 that was > discussed is to introduce the concept of named permission sets. In > particular, instead of having a permission-mapping reference permissions, > it would instead reference named permission-sets. This would allow the > provisioning tool to be able to add/remove permissions to/from a default > permission-set based on the presence/absence of a specific subsystem when > generating the default configuration. However, as Alexey pointed out, this > doesn't solve the problem of knowing which permission-mapping a > permission-set should be added to when attempting to preserve user > configuration changes for patching, version updates, etc. > Right. It does not change the permission-mappings, they remain to be a list of items with no identity. Which is the fundamental problem. Thanks, Alexey Thanks, > Farah > > On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < > alexey.loubyansky(a)redhat.com&gt; wrote: > >> While this is addressed mainly to the Elytron team, it seems like we >> would appreciate opinions from other colleagues since we are basically >> stuck discussing possible ways to resolve https://issues.jboss.org/brows >> e/WFCORE-3596 >> >> The description in the jira is pretty brief assuming people know what >> that is about, since it's been raised before multiple times. Here is what >> it is about fundamentally. >> >> If a configuration model (of a subsystem or any other component) >> includes a list of configurable units (let's assume XML elements for >> simplicity) that don't have any identity (unique id/name/path/etc) this is >> a big problem for supporting patching and version updates preserving user >> configuration changes. Or simply customizing the default config model using >> a tool. By a big problem I mean it's simply not going to work reliably. >> >> As a simple exercise that demonstrates the issue, imagine you have two >> configs each of which includes a list of these configurable units that have >> no identity. Now try to identify the difference between the two lists. Or >> merge them with one overwriting the other. Basically components w/o an >> identity can not be manipulated. You can only add them but not modify or >> even remove (unless their index in the list is a constant value of course). >> >> I don't think I've seen any issue of this kind in our (WF/EAP) configs >> except for the Elytron's permission-mapping's. (If somebody knows such >> components please let me know). >> If I misunderstand the Elytron config model or approaching this from a >> wrong angle, please let me know. >> >> Question for the Elytron team: is the problem I am describing clear? Do >> you admit it as a problem? >> >> Thanks, >> Alexey >> > >

On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < alexey.loubyansky(a)redhat.com&gt; wrote: > On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com&gt; wrote: > >> A solution to part of the problem mentioned in WFCORE-3596 that was >> discussed is to introduce the concept of named permission sets. In >> particular, instead of having a permission-mapping reference permissions, >> it would instead reference named permission-sets. This would allow the >> provisioning tool to be able to add/remove permissions to/from a default >> permission-set based on the presence/absence of a specific subsystem when >> generating the default configuration. However, as Alexey pointed out, this >> doesn't solve the problem of knowing which permission-mapping a >> permission-set should be added to when attempting to preserve user >> configuration changes for patching, version updates, etc. >> > > Right. It does not change the permission-mappings, they remain to be a > list of items with no identity. Which is the fundamental problem. > But why is that a problem? I think that is the piece still missing. By moving the list of the permissions into a single named resource the tooling no longer has a need to be performing the manipulation within the simple permission mapper so that can be left to the administrator to look after independently.

> > Thanks, > Alexey > > Thanks, >> Farah >> >> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >> alexey.loubyansky(a)redhat.com&gt; wrote: >> >>> While this is addressed mainly to the Elytron team, it seems like we >>> would appreciate opinions from other colleagues since we are basically >>> stuck discussing possible ways to resolve https://issues.jboss.org/ >>> browse/WFCORE-3596 >>> >>> The description in the jira is pretty brief assuming people know what >>> that is about, since it's been raised before multiple times. Here is what >>> it is about fundamentally. >>> >>> If a configuration model (of a subsystem or any other component) >>> includes a list of configurable units (let's assume XML elements for >>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>> a big problem for supporting patching and version updates preserving user >>> configuration changes. Or simply customizing the default config model using >>> a tool. By a big problem I mean it's simply not going to work reliably. >>> >>> As a simple exercise that demonstrates the issue, imagine you have two >>> configs each of which includes a list of these configurable units that have >>> no identity. Now try to identify the difference between the two lists. Or >>> merge them with one overwriting the other. Basically components w/o an >>> identity can not be manipulated. You can only add them but not modify or >>> even remove (unless their index in the list is a constant value of course). >>> >>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>> except for the Elytron's permission-mapping's. (If somebody knows such >>> components please let me know). >>> If I misunderstand the Elytron config model or approaching this from a >>> wrong angle, please let me know. >>> >>> Question for the Elytron team: is the problem I am describing clear? Do >>> you admit it as a problem? >>> >>> Thanks, >>> Alexey >>> >> >> _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

While this is addressed mainly to the Elytron team, it seems like we would appreciate opinions from other colleagues since we are basically stuck discussing possible ways to resolve https://issues.jboss.org/browse/WFCORE-3596 The description in the jira is pretty brief assuming people know what that is about, since it's been raised before multiple times. Here is what it is about fundamentally. If a configuration model (of a subsystem or any other component) includes a list of configurable units (let's assume XML elements for simplicity) that don't have any identity (unique id/name/path/etc) this is a big problem for supporting patching and version updates preserving user configuration changes. Or simply customizing the default config model using a tool. By a big problem I mean it's simply not going to work reliably. As a simple exercise that demonstrates the issue, imagine you have two configs each of which includes a list of these configurable units that have no identity. Now try to identify the difference between the two lists. Or merge them with one overwriting the other. Basically components w/o an identity can not be manipulated. You can only add them but not modify or even remove (unless their index in the list is a constant value of course). I don't think I've seen any issue of this kind in our (WF/EAP) configs except for the Elytron's permission-mapping's. (If somebody knows such components please let me know). If I misunderstand the Elytron config model or approaching this from a wrong angle, please let me know. Question for the Elytron team: is the problem I am describing clear? Do you admit it as a problem? Thanks, Alexey _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: > On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < > alexey.loubyansky(a)redhat.com&gt; wrote: > >> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com&gt; wrote: >> >>> A solution to part of the problem mentioned in WFCORE-3596 that was >>> discussed is to introduce the concept of named permission sets. In >>> particular, instead of having a permission-mapping reference permissions, >>> it would instead reference named permission-sets. This would allow the >>> provisioning tool to be able to add/remove permissions to/from a default >>> permission-set based on the presence/absence of a specific subsystem when >>> generating the default configuration. However, as Alexey pointed out, this >>> doesn't solve the problem of knowing which permission-mapping a >>> permission-set should be added to when attempting to preserve user >>> configuration changes for patching, version updates, etc. >>> >> >> Right. It does not change the permission-mappings, they remain to be a >> list of items with no identity. Which is the fundamental problem. >> > > But why is that a problem? I think that is the piece still missing. > > By moving the list of the permissions into a single named resource the > tooling no longer has a need to be performing the manipulation within the > simple permission mapper so that can be left to the administrator to look > after independently. > Is your question why is it a problem to give these things an identity? If so, I have the same question, although I don't think Alexey's the one to come up with the identity. Or is your question why is not having an identity a problem? If so, is it correct to say that getting rid of this bit of wrongness is the problem: https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/reso... Basically right there elytron is speculatively providing configuration rightly owned by other subsystems. To do this correctly, each of those permissions should be part of the config established by other parts of the system. The provisioning tool is expected to do it correctly. And doing that requires some sort of identity for each item in the set. . Installing a feature should involve adding independent, identifiable chunks of config, not manipulating an attribute of some chunk of config owned by a different feature. Manipulating an attribute is not feasible and isn't correct. > >> >> Thanks, >> Alexey >> >> Thanks, >>> Farah >>> >>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>> alexey.loubyansky(a)redhat.com&gt; wrote: >>> >>>> While this is addressed mainly to the Elytron team, it seems like we >>>> would appreciate opinions from other colleagues since we are basically >>>> stuck discussing possible ways to resolve >>>> https://issues.jboss.org/browse/WFCORE-3596 >>>> >>>> The description in the jira is pretty brief assuming people know what >>>> that is about, since it's been raised before multiple times. Here is what >>>> it is about fundamentally. >>>> >>>> If a configuration model (of a subsystem or any other component) >>>> includes a list of configurable units (let's assume XML elements for >>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>> a big problem for supporting patching and version updates preserving user >>>> configuration changes. Or simply customizing the default config model using >>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>> >>>> As a simple exercise that demonstrates the issue, imagine you have two >>>> configs each of which includes a list of these configurable units that have >>>> no identity. Now try to identify the difference between the two lists. Or >>>> merge them with one overwriting the other. Basically components w/o an >>>> identity can not be manipulated. You can only add them but not modify or >>>> even remove (unless their index in the list is a constant value of course). >>>> >>>> I don't think I've seen any issue of this kind in our (WF/EAP) configs >>>> except for the Elytron's permission-mapping's. (If somebody knows such >>>> components please let me know). >>>> If I misunderstand the Elytron config model or approaching this from a >>>> wrong angle, please let me know. >>>> >>>> Question for the Elytron team: is the problem I am describing clear? >>>> Do you admit it as a problem? >>>> >>>> Thanks, >>>> Alexey >>>> >>> >>> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat