<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thanks Brian, <br>
</p>
<p>reply inlined.<br>
</p>
<br>
<div class="moz-cite-prefix">On 04/12/2018 23:15, Brian Stansberry
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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"
moz-do-not-send="true">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>
</div>
</blockquote>
It is a layer introduced to be able to provision a complete default
standalone configuration without inheriting default packages (that
contains all modules). Your question makes me realize that it could
be hidden by having the default config to simply includes the
package (what the layer does).<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
The size is 38MB. The provisioned standalone servlet config is
around 55MB.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
For now the tools layer embeds all tools. I used to have layers for
each kind of tools (tools, ejb-appclient, wstools, jdr,
jboss-client, jboss-cli-client) but decided to group them all for
the first step. It seems that, according to the cloud context
requirements, only the core-tools should be layerized (cli, add-user
and elytron). Other tools being provisioned with default dist.<br>
<br>
We have jaxrs that depends on web-server, we would provision:
jaxrs,elytron,management,tools The command would look like: <br>
<br>
install wildfly:current#16.0.0.Beta1-SNAPSHOT --dir=server
--layers=jaxrs,management,elytron,tools<br>
<br>
The size with all tools is 155MB, with core tools: 64MB<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
At the configuration level it only configures a local cache
hibernate-cache but in terms of modules, it brings jgroups. <br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
Yes.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
Yes, splitting tools give us much better footprint. We should only
incorporate core tools in a core-tools layer for now.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
The provisioning of cloud-profile alone is 121MB. This is the size
of the layers with all the optional dependencies injected from DUP
(minus passives that are not incorporated eg: weld.ejb). Some of
them are quite big and would be not required in all cases. For
example, by excluding:<br>
org.jboss.weld.probe (cdi debug)<br>
org.hibernate.search.orm (hibernate search)<br>
org.jboss.resteasy.resteasy-crypto (jaxrs crypto, brings
bouncycastle)<br>
org.jboss.resteasy.resteasy-multipart-provider (brings email,
multipart support).<br>
<br>
the cloud-profile size is down to 108MB.<br>
<br>
By not bringing any such optional deps we are at 104MB, but that is
to my point of view safer to guarantee that these optional are
provisioned and exclude the un-needed.<br>
<br>
The size of cloud-profile and all its deps + core tools is 126MB. As
a comparison, full provisioned standalone config is 212MB<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
core tools (add-user, cli, elytron-tool) on top of base-server
brings 7MB. We could see if we can reduce that.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
elytron has a dependency on picketbox for jacc.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</div>
</blockquote>
no description, no metadata, yes that would help.<br>
<blockquote type="cite"
cite="mid:CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
<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"
moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br>
<a
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">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>
</blockquote>
<br>
</body>
</html>