<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">This sounds pretty reasonable. There are a lot of layers but the aggregation layers let people deal with things with a reasonable granularity.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">In the future in the tooling I don&#39;t know if there&#39;s a way to annotate layers somehow so some get some sort of prominence in the UI (a la what the WF CLI does with required attributes and tab completion.)  That&#39;s a very vague thought though, and something for the future.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">More inline...</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 11:54 AM Jean-Francois Denise &lt;<a href="mailto:jdenise@redhat.com">jdenise@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
here is an attempt to describe the galleon layers we could see exposed <br>
in order to build custom configurations. The way layers are provisioned <br>
by galleon make the provisioned server to be much smaller (in term of <br>
XML config and num of provisioned modules) than the default <br>
installation/configurations. We are here covering standalone kind of <br>
configuration.<br>
<br>
Feedbacks would be really welcome.<br>
<br>
I took the approach to not have layers to depend on legacy <br>
security-realms, we want elytron to be the way to go, so depending on <br>
these first place would create a maintainability issue. This does create <br>
some complexity when defining default configs, default config have to <br>
associate realms with management and subsystems to produce the default <br>
standalone configs we know. This complexity is not exposed.<br>
<br>
Each layer is &quot;runnable&quot;, you can provision it and run it. Only common.* <br>
and standalone.* scripts are provisioned. Doesn&#39;t mean that running it <br>
alone makes sense.<br>
<br>
Any combination of layers should be valid.<br>
<br>
A layer brings its own dependencies and its XML configuration. Each <br>
subsystem (even server) is in charge to advertise to galleon what are <br>
the additional modules it is injecting or loading that should be <br>
provisioned but are not referenced from extension module. All the <br>
subsystems involved in the following layers have been updated to express <br>
these dependencies.<br>
<br>
Because Full layers are far from being defined, we could expect some <br>
adjustment.<br>
<br>
For core:<br>
<br>
Layers not bound to subsystems<br>
<br>
- base-server: root resource, pubic interface and socket binding. All <br>
layers depend at least on it.<br>
- management: unsecured management interface, management sockets, <br>
http-interface<br>
- secure-management: depends on management, configures elytron sasl <br>
authentication factory for management http interface<br>
- tools: all modules and tools script files (cli, add-user,...)<br>
- patching: patching modules.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">AFAIK legacy patching won&#39;t work with a custom Galleon provisioned server. Is this layer just here as necessary bit to let us produce our standard dists, or do you see it being used for custom servers?</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Layers bound to subsystems<br>
<br>
- core-management<br>
- deployment-scanner<br>
- discovery<br>
- elytron (brings openssl artifacts, openssl can&#39;t be used if elytron <br>
openssl provider is not configured.).<br>
- io<br>
- jmx<br>
- jmx-remoting: depends on jmx and configure remoting-connector. Depend <br>
on management (requires jboss.remoting.endpoint.management service)<br>
- logging<br>
- remoting: depends on io<br>
- request-controller<br>
- security-manager<br>
<br>
Aggregation Layer<br>
<br>
This layer defines a server with elytron secured management and all <br>
layers one would expect when running a core-server<br>
<br>
- core-server: depends on secure-management (brings elytron), <br>
jmx-remoting (brings jmx), logging, core-management, request-controller, <br>
security-manager.<br>
<br>
For servlet<br>
<br>
Layers not bound to subsystems<br>
<br>
- picketbox: A layer to brings picketbox module (and optional deps of <br>
picketbox present in servlet FP). Picketbox could be combined with some <br>
core layers without requiring the legacy security subsystem to be present.<br>
<br>
Layers bound to subsystems<br>
<br>
- ee: depends on naming<br>
- legacy-security (security sub-system): depends on naming and picketbox.<br>
- naming<br>
- undertow: depends on io and picketbox (to bring optional deps of <br>
picketbox, we still have hard dep on picketbox from <br>
security-negociation). This is a base undertow server, no security, no <br>
https-listener, empty servlet container (no support for servlet, jsp <br>
deployments). NB: welcome-content is not part of the layer, it is bring <br>
by the default configs. legacy default-security-domain &quot;other&quot; is also <br>
not configured, that is done in the default config too.<br>
- undertow-load-balancer: depends on io and picketbox. Undertow <br>
configured to act as a load-balancer.<br>
<br>
Web server layer<br>
<br>
This layer defines a server containing all layers one would expect when <br>
running an unsecure web-server. legacy-security is not included. In <br>
addition, this layer evolves undertow to be a full servlet-container <br>
(jsp, servlet, web-socket) and http-invoker.<br>
<br>
- web-server: ee (brings naming), deployment-scanner, undertow (brings <br>
picketbox and io)<span style="font-family:&quot;trebuchet ms&quot;,sans-serif"></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A note on combining layers.<br>
<br>
In order to evolve a web-server to become fully manageable, one would <br>
combine core-server (the management features) with web-server (web <br>
support). </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Because core layers are accessible from servlet FP, one could pick and <br>
choose from servlet FP to assemble his server. For example, a basic <br>
manageable unsecured (but ready to be configured for security) undertow <br>
server: undertow+management+elytron<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">What, roughly, is the disk footprint of an installation like this? I mean with known tweaks and optimizations you have in your WIP.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div><span style="font-family:&quot;trebuchet ms&quot;,sans-serif">What, roughly do the Galleon CLI commands look like to provision a server with this, plus, say core tools and jaxrs from the full feature pack?</span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
For full:<br>
<br>
We have identified an initial set of layers that would be the building <br>
blocks to help define cloud oriented configurations.<br>
<br>
Layers bound to subsystem:<br>
<br>
These layers depend (at least) on web-server (from servlet)<br>
<br>
- cdi: brings in weld and bean-validation<br>
- jaxrs<br>
- jpa: brings in hibernate default providers. In addition brings-in <br>
transactions, jca and infinispan (hibernate infinispan-cache).<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Does that bring in JGroups? Or is this a local-only cache?</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- activemq-jms: naked subsystem, no server configured. In addition <br>
brings-in transactions and jca<br>
- microprofile: opentracing, config, healths and metrics (last 2 depend <br>
on management).<br>
<br>
Layers that are simple extension of existing layers (would not appear as <br>
new layers but would extend content of servlet/core ones).<br>
<br>
- ee: add optional dependencies injected by dup present in full FP.<br>
- undertow: add undertow.js package.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">I&#39;m curious why this is only in full. Not really a question for you as I assume you put it in full because that&#39;s where it is now.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- tools: vault, jdr, wstools, appclient<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">This might need some tweaking. AIUI appclient would bring in nearly the entire current installation, so perhaps should be independent. I don&#39;t know about wstools.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Aggregation layer<br>
<br>
- cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile . All <br>
optionally included, allowing for exclusion (eg: exclude activemq-jms).<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">What the rough footprint of this, with core tools added?</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Open questions<br>
<br>
SSL undertow<br>
<br>
As you noticed we don&#39;t have a layer for an SSL undertow. elytron <br>
doesn&#39;t offer an out of the box generation of self-signed certificate. <br>
Only legacy security realms offer this. So the way to go would be to <br>
provision undertow+elytron+management+tools (management+tools to use <br>
CLI), create the keystore, do the elytron configuration, add an <br>
https-listener, set the ssl-context, remove all the management related <br>
stuff from CLI. Then exclude the management+tools layers to get a <br>
smaller foot-print (tools bring a lot). </blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Having tools take a lot is something to attack. CLI in particular. The CLI is useful on OpenShift as the OS console gives you a terminal on each pod from which you can start a local CLI session. That lets you do diagnostic stuff things like tweak log levels etc.  The CLI also gets used for things like health/readiness probes and shutdown.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">NB: we could imagine that the <br>
CLI configuration is done from a provisioned server that contains tools <br>
so no need to provision tools with undertow.<br>
<br>
I am wandering if we should create an elytron SSL context that points to <br>
a &quot;REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE&quot; kind of configuration to <br>
simplify configuration steps? I don&#39;t really like this idea to generate <br>
config that points to invalid artifacts but would simplify the <br>
configuration steps.<br>
<br>
Picketbox layer<br>
<br>
Because we want at some point to get rid-off this dependency, I am <br>
wandering if we should really define a layer for it. Could be that any <br>
dependency on it would imply the use of legacy-security layer. Picketbox <br>
is implicit when legacy-security layer is provisioned.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">The independent use is the management vault. Using that shouldn&#39;t require everything in the current p-b module though. And arguably you could say that use case means you need the vault tool and thus whatever layer has it. (You don&#39;t need the vault tool though, not on the server.)</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Is there any metadata type concept for marking a layer as deprecated etc?</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Full layers granularity<br>
<br>
For now, we have included some major features (transactions, jca, <br>
infinispan) without making them layers. The layers that are depending on <br>
them are for the only consumers. When we progress with new layers, this <br>
would be revisited.<br>
<br>
Thank-you for having reached the end. ;-)<br></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">Phew!</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
JF<br>
<br>
_______________________________________________<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/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>