<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't know if there'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'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 <<a href="mailto:jdenise@redhat.com">jdenise@redhat.com</a>> 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 "runnable", you can provision it and run it. Only common.* <br>
and standalone.* scripts are provisioned. Doesn'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:"trebuchet ms",sans-serif">AFAIK legacy patching won'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:"trebuchet ms",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'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 "other" 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:"trebuchet ms",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:"trebuchet ms",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:"trebuchet ms",sans-serif"><br></div><div><span style="font-family:"trebuchet ms",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:"trebuchet ms",sans-serif">Does that bring in JGroups? Or is this a local-only cache?</div><div class="gmail_default" style="font-family:"trebuchet ms",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:"trebuchet ms",sans-serif">I'm curious why this is only in full. Not really a question for you as I assume you put it in full because that's where it is now.</div><div class="gmail_default" style="font-family:"trebuchet ms",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:"trebuchet ms",sans-serif">This might need some tweaking. AIUI appclient would bring in nearly the entire current installation, so perhaps should be independent. I don't know about wstools.</div><div class="gmail_default" style="font-family:"trebuchet ms",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:"trebuchet ms",sans-serif">What the rough footprint of this, with core tools added?</div><div class="gmail_default" style="font-family:"trebuchet ms",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't have a layer for an SSL undertow. elytron <br>
doesn'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:"trebuchet ms",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:"trebuchet ms",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 "REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE" kind of configuration to <br>
simplify configuration steps? I don'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:"trebuchet ms",sans-serif">The independent use is the management vault. Using that shouldn'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't need the vault tool though, not on the server.)</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">Is there any metadata type concept for marking a layer as deprecated etc?</div><div class="gmail_default" style="font-family:"trebuchet ms",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:"trebuchet ms",sans-serif">Phew!</div><div class="gmail_default" style="font-family:"trebuchet ms",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>