[keycloak-dev] wildfly pkg manager changes everything

[Bill Burke]

On Thu, Apr 5, 2018 at 2:28 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I don't have the full picture yet on how this will all work, but it sounds
> really promising.
>
> There are at least 3 categories of users for Keycloak:
>
> * Black box users - built-in features and config options are sufficient

What the new WPM will allow us to do is define a bare bones distros.
People that want to write extensions using other components (i.e. EJB,
JMS, etc...) can use WPM to bring in those dependencies.

> * Middle ground - customized themes and a few custom providers, but still
> happy with a default setup with regards to subsystems (and limited use of
> JEE features)
> * Integration - more heavily customized and have a need to add additional
> subsystems on top of what we bring
>
> I would believe most users land in the first two and would be happy with a
> single distro download rather than having to install a package manager to
> then install. For the latter the approach to combine your own would be
> great.
>

Jason envisions a base Wildfly image that is just a maven repo.
Layered products like keycloak just ship a thin extension image that
points into the repo of the base image.  This extension image is just
config files.  Very tiny and compact.  This gives a lot of room for
optimization in the cloud layer as other non-keycloak apps built on
wildfly and eap and rhoar can also point into this base image.

For us, I think the steps should be:
1. download keycloak which will come included with WPM
2. add your db driver

$ wpm install my-db-driver

3. Modify Wildfly config by hand or with jboss cli as needed
4. Modify add themes as needed
5. Develop extensions as needed
if writing an extension that uses EJB and JMS

$ wpm install EJB JMS

You have something working, now its time to put shit into your cloud environment

1. Your development distro (just a set of config files) is packaged
and pushed to your company maven repo.  (Yes, WPM will allow you to do
this).  What's interesting about this development distro is that it is
just a set of config files and is very very tiny.
2. Extend the development distro to add production parameters.  yes,
you can have one distro depend on another!

$ wpm install kube-ping

3. Add a stock Dockerfile to your extended "production" distro.
This stock Dockerfile extends base Wildfly or EAP image (which is just
a maven repo).
4. Build and push your new production image.  This new image is really
tiny...measured in kilobytes as it points into the maven repo that
comes with the base Wildfly/EAP image.

Oh...we need to move our distro to Amazon AWS.  We need a different DB
and a different JGroups stack

1. Extend the production distro and make changes:
$ wpm remove my-db-driver
$ wpm remove keycloak-jpa
$ wpm install keylcloak-s3
$ wpm remove kube-ping
$ wpm install s3-ping
$ jboss-cli ...

Repeat steps 3 and 4 above to build a new image.  What's cool is that
WPM creates a history file that can be replayed.  So all the steps
above are ready to copy and throw in a Dockerfile

Let's pretend that we would have to have a different keycloak
deployment per cloud provider (AWS vs. GCE vs. on premise Openshift
vs. Openshift Online).  We could prepackage this stuff with additional
service packs.  Then you could extend the custom development service
pack we defined earlier and do this instead:

$ wpm install keycloak-aws

There's just so much flexibility for our users, for Wildfly, and for
the cloud provider. So much potential for re-use and optimization.

All and all, I think your viewpoint doesn't match the actual reality
of how people are going to consume Keycloak.  I'm not alone.  In my
talks with Jason, he also thought the ENV VAR approach is just crazy.
 He has the exact same concerns with the Wildfly XPaaS image that I do
with Keycloak's.   There's a reason that their are a million settings
in the application server.  This tech has been around for 15 years and
people do a lot of crazy shit.  I would say 100% of "actual" users
will extend the themes.  I think close to 100% will need to modify
configuration, install their own database driver, tweek undertow
config,  turn on/turn off wildfly management layer etc. etc. etc..
I'm not even 100% sure that we can ship with a stock JGroups stack for
Openshift and this might have to change depending on the cloud
provider.  I think a majority of developers will have to write an
extension at some point.  Finally, I would also say that there will be
a large chunk of developers that will want as slim a Keycloak as
possible.  I think Spring proves how prevalent this "deploy only what
you need" ideology is.  I think developers will outgrow "hello world"
and the base image very very quickly.

IMO, almost everybody will want to work locally on their laptop,
develop and test their deployment there rather than the crazy model
being pushed right now around S2I and constantly recycling and
redeploying your image.  Think about it....Would you restart your
laptop every time you made a codechange while developing?  IMO, the
best approach is to bridge the divide between local development and
cloud deployment.  Let people define and test their deployment locally
as well.  This isn''t solely a Keycloak problem.  Every app of every
language and framework will have it.

Anyways, that's my rant, viewpoint, and prediction.