[keycloak-dev] wildfly pkg manager changes everything

[Bill Burke]

That is my understanding.  I think the timeline is that it will just
be used internally to build releases for various product service packs
this summer.  Then the next release of Wildfly after that will make
WPM public.  My biggest hope is, with this, why would you need to
build RPMs anymore when you have something that does exactly the same
things as yum, except cross platform.

On Thu, Apr 5, 2018 at 2:11 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> All that seems awesome ....
>
> So, WPM would basically use maven artifacts to represent layers in your
> distro (like we have in docker for any additional stuff you want into an
> image) ?
>
> On Thu, Apr 5, 2018 at 1:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> 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.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat