<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 27, 2018 at 2:06 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@redhat.com" target="_blank">darran.lofthouse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How do you cope with things like a login module stack in the security subsystem? That is also ordered where the order has a very specific meaning. I haven't checked the configuration recently but doesn't configuration for jgroups also handle the configuration in an ordered way that an administrator could choose to modify?</div></blockquote><div><br></div><div>They (login module stack and jgroup's protocol stack) are different in that every item on the stack has an identity. So I can see whether an item has been removed, modified or a new one added. I can't see how I can do that with the permission-mapping. This is my main problem at the moment.</div><div><br></div><div>About the ordered collections in general, yes, there is an issue. Like you mentioned, for a start the order can be pre-defined (it can later be re-defined although that appears to be not as easy as it should be). This is actually how it currently works.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The proposal we have so far is to remove the need for the manipulation of permissions in the ordered list as other subsystems are added / removed - at this point the remaining config in the permission mapper should either match the default we ship or if it is modified this should be as a result of administrator action so should be preserved as is.</div></div></blockquote><div><br></div><div>Right, I get that. The thing is that if it is modified, it has to be fully re-defined, meaning it's not a fine-grained adjustment. Because if you want to add another permission (or the named permission-set) how to can the target permission-mapping be determined?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The problem we have with the resource now is it must be preserved for backwards compatibility. Broadly this means we have the following two requirements: -</div><div> 1 - Any changes we make must be transformable to the prior version of the resource.</div><div> 2 - XML configuration for a prior version of the resource must be convertible to the new version.</div></div></blockquote><div><br></div><div>The good thing is that XML is not what is being manipulated, the representation of the resource in the domain management model is. Not meaning it gives a complete freedom but it's a good thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Alternatively we could redesign a new resource from scratch to provide model based permission mapping but a redesign from scratch is unlikely to completely cover #1 and #2 so we could end up with a deprecated resource which is not immediately removable although if we can achieve #1 removal possibly could be faster.</div><div><br></div><div>But is all this necessary at the moment? Especially as at the moment we do have a proposal that moves the permissions we know need to be updated to an identifiable resource.</div></div></blockquote><div><br></div><div>What about the permission-mapping? Are there plans to do anything with them?</div><div><br></div><div>To me, it depends on what you mean by "at the moment". If you mean whether the changes need to be implemented and usable in a few weeks, no. But I think not giving it a priority now is a bad thing, because as you wrote above then we have to support the structure which limits the ability to customize the default configs, perform integration, updates and preserving user changes.</div><div><br></div><div>Thanks,</div><div>Alexey</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="m_5137679481053649745HOEnZb"><font color="#888888"><div><br></div><div>Darran.</div><div><br></div></font></span></div><div class="m_5137679481053649745HOEnZb"><div class="m_5137679481053649745h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky <<a href="mailto:alexey.loubyansky@redhat.com" target="_blank">alexey.loubyansky@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@redhat.com" target="_blank">darran.lofthouse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue? I am sure we have other examples of ordered lists out there.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. I<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">dentifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well.</span></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div>Alexey</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728HOEnZb"><font color="#888888"><div><br></div><div>Darran.</div><div><br></div></font></span></div><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728HOEnZb"><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728h5"><br><div class="gmail_quote"><div dir="ltr">On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <<a href="mailto:alexey.loubyansky@redhat.com" target="_blank">alexey.loubyansky@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@redhat.com" target="_blank">darran.lofthouse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Ok so lets switch this another way.</div><div><br></div><div>If the addition from other subsystems was to be eliminated is there still a provisioning issue?</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.</div><div><br></div><div>Thanks,</div><div>Alexey</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232h5"><div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232m_-7488140712470423362m_-151495070846696298gmail-"><div dir="ltr">On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <<a href="mailto:alexey.loubyansky@redhat.com" target="_blank">alexey.loubyansky@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <span dir="ltr"><<a href="mailto:fjuma@redhat.com" target="_blank">fjuma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. <br></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Right. It does not change the permission-mappings, they remain to be a list of items with no identity. Which is the fundamental problem.</div></div></div></div></blockquote><div><br></div></span><div>But why is that a problem? I think that is the piece still missing.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125" target="_blank">https://github.com/wildfly/wil<wbr>dfly-core/blob/master/elytron/<wbr>src/main/resources/subsystem-<wbr>templates/elytron.xml#L125</a></div><div><br></div><div>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. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Manipulating an attribute is not feasible and isn't correct.</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232m_-7488140712470423362m_-151495070846696298gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Thanks,</div><div>Alexey</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks,</div><div>Farah</div></div><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232m_-7488140712470423362m_-151495070846696298gmail-m_1296326077637878153m_1352572413483716643HOEnZb"><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232m_-7488140712470423362m_-151495070846696298gmail-m_1296326077637878153m_1352572413483716643h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky <span dir="ltr"><<a href="mailto:alexey.loubyansky@redhat.com" target="_blank">alexey.loubyansky@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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 <a href="https://issues.jboss.org/browse/WFCORE-3596" target="_blank">https://issues.jboss.org/brows<wbr>e/WFCORE-3596</a></div><div><br></div><div>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 <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">fundamentally</span>.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).<br></div><div>If I misunderstand the Elytron config model or approaching this from a wrong angle, please let me know.</div><div><br></div><div>Question for the Elytron team: is the problem I am describing clear? Do you admit it as a problem?</div><div><br></div><div>Thanks,</div><div>Alexey</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div></blockquote></span></div></div>
<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div class="m_5137679481053649745m_-7730424936006222383m_1692932867544385728m_1795094841259267788m_7245186885727396232m_-7488140712470423362m_-151495070846696298gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</div></div></blockquote></div></div></div></div>
</blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div><br></div></div>