On 6/4/14, 12:48 PM, Jason Greene wrote:
On Jun 4, 2014, at 12:23 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
> There is of course ways to paper over this and shove them together but you end up
with leaky abstractions. Like lets say the CLI could issue REST operations against
Keycloak as well. Thats great but that means things like the compensating transaction
model don’t let you mix management changes with keycloak changes.
>
> Another issue is that WildFly has some pretty strict backwards compatibility
contracts with regards to management that stem from EAP. Keycloak, at this stage of the
process might not want to put up with us requesting similar conservative governance. It
might be better for us to limit the API dependencies to best enable the project to
continue to evolve.
Other problems I forgot to mention (oops sorry!)
1. Lifecycle robustness problems - Management is not supposed to affect applications, so
if the user takes down or moves the DC it would take down application auth as well - Bad!
2. Chicken-egg problems in standalone mode - subsystems aren’t started when the server is
in admin-only mode. (Although this one is solvable)
Subsystem services aren't started only because operation handlers by
default don't do runtime stuff in admin-only mode. But a subsystem
author could certainly have their handlers do stuff in admin-only if it
was appropriate.
Your comment however makes me realize a flaw in how I'd been seeing
this, where the Keycloak server could simply be an application running
on one of the servers in the domain. But servers are under the control
of an HC, and an HC in admin-only will not launch servers. So there's a
chicken-egg issue there.
3. Lots of additional work.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat