Seems like the majority (that being everyone besides me) would like to have
the script renamed. So let's go for it, but first I have two questions:
a) What should it be called (it can't be add-user-keycloak.sh as then it
wouldn't make sense in product)? add-user-sso.sh is an idea, but is it
clear that's adding "Keycloak admin console" users
b) Will we not get a bunch of people asking "I added a user with add-user,
but still can't login to Keycloak admin console"? Do we have a solution for
that?
On 25 April 2016 at 03:41, Stan Silvert <ssilvert(a)redhat.com> wrote:
On 4/24/2016 2:58 PM, Bill Burke wrote:
> Completely different. standalone.sh and domain.sh are completely new
> run.sh variants and run.sh disappeared.
Nope. If there was no domain.sh we would have kept run.sh.
standalone.sh does exactly the same thing run.sh used to do.
Furthermore, run.sh didn't disappear. It just prints a helpful message.
The situation here is exactly the same. If there was no "keycloak"
add-user we would have kept the old one.
Bill, I agree that the current situation is confusing. Stian, I agree
that having both "add-user.sh" and "add-user-keycloak.sh" is also
confusing.
The WildFly solution isn't pretty, but at least it isn't confusing.
I suppose you could make the whole thing prettier by slapping some extra
UI into the unified version. Let it prompt the user for what he really
wants to do, etc., etc.
>
> add-user.sh is the same script as the old. and you've already had two
> Red Hat people scratching their heads wondering what happened to
> add-user.sh.
Were you including me? I complained about this several weeks ago, so
perhaps you can make that three Red Hat people. I agree that it's a
problem.
>
> On 4/23/2016 3:04 PM, Stan Silvert wrote:
>> We had the same kind of problem in WildFly a few years ago. Everyone
>> was used to starting the server with run.sh. But we needed to change
>> that to differentiate between standalone.sh and domain.sh. So we made
>> run.bat just print out a "This is deprecated. Here is what you need to
>> do...." message.
>>
>> It's not a perfect solution, but we could do the same thing with
>> add-user.sh and tell them to use either add-user-keycloak.sh or
>> add-user-eap.sh. At least you wouldn't get any support questions.
>>
>> On 4/23/2016 9:06 AM, Ilya Rum wrote:
>>> Hello!
>>>
>>> As a new member of keycloak QA team I recently had to set up some
>>> clustering with domain mode.
>>> I was really confused when add-user.sh did not add user to jboss but
>>> rather created the keycloak-add-user.json.
>>> The worst thing was that I couldn't find any docs on adding user to
>>> underlying eap at all.
>>> Had to read the add-user.sh itself to find out what was happening.
>>> Even if it remains as it is, it really should be at least mentioned in
>>> the docs :)
>>>
>>> Have a nice day!
>>> Ilya Rum.
>>>
>>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote:
>>>> Do you care about usability at all? Not everything can fit into nice
little
>>>> boxes all the time. This is going to be extremely confusing for
users. I
>>>> ran into it myself as I thought the jboss add-user.sh script was
overwritten
>>>> by our distribution script by mistake. *OF COURSE* we should have a
>>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate
to
>>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss
platform, and
>>>> this means the JBoss documentation too, every management function that
>>>> exists in JBoss should be available in Keycloak and *WORK THE SAME
WAY*. If
>>>> we don't change this, we're going to get a ton of support
questions
that
>>>> say: "Why doesn't add-user.sh work?"
>>>>
>>>>
>>>>
>>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote:
>>>>> In the future we need to secure the underlying WildFly with rhsso.
In
>>>>> which case our add-user will add users for both Keycloak and
WildFly/EAP.
>>>>>
>>>>> IMO there's going to be confusion until the above is solved no
matter what
>>>>> we do. We'll need to document this whichever way we do it.
Options
are
>>>>> stay with what we have or rename our script. My vote goes to keep
as
is
>>>>> and document it. Then hopefully by 7.1 we can secure the WildFly
bits so
>>>>> the problem goes away. With the other option (rename ours) there
will be a
>>>>> problem once WildFly bits are secured by Keycloak as now the wf
add-user
>>>>> script should no longer be used and completely removed at which
point we
>>>>> should then rename it back. So in the long run sticking with how it
is
>>>>> today is ideal. It's also way to late making changes now. BTW
this
has
>>>>> been around for months.
>>>>>
>>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com
>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 4/22/2016 3:57 PM, Marek Posolda wrote:
>>>>> > That's the question...
>>>>> >
>>>>> > For server distribution, we also have our stuff (
keycloak
>>>>> subsystem,
>>>>> > datasource, infinispan etc) directly declared in
>>>>> "standalone.xml". On
>>>>> > the other hand, for overlay distribution, we don't
want to
directly
>>>>> > update default "standalone.xml", so we are
adding our own
>>>>> > "standalone-keycloak.xml". Isn't it quite
similar thing?
>>>>> >
>>>>>
>>>>> Product will not have the overlay distribution.
>>>>>
>>>>> > We can do the same for overlay and server distribution,
so
never
>>>>> edit
>>>>> > default wildfly files ( standalone.xml , add-user.sh),
but
>>>>> always use
>>>>> > our own versions with "-keycloak" suffix.
Advantage is more
>>>>> > consistent. However people will need to always start
keycloak server
>>>>> > with "./standalone.sh -c
standalone-keycloak.xml" then.
Doesn't it
>>>>> > sucks from the usability perspective?
>>>>> >
>>>>>
>>>>> The overlay exists because we can't distribute EAP within
community.
>>>>> Keycloak should be run as a separate server, so, IMO,
-keycloak.xml
>>>>> files should go away and overwrite standalone.xml,
>>>>> standalone-ha.xml and
>>>>> domain.xml
>>>>>
>>>>> > I honestly don't know what's the best way
regarding
usability. AFAIK
>>>>> > this was decided on mailing lists couple of months ago,
but
don't
>>>>> > remember the exact threads...:/
>>>>> >
>>>>>
>>>>> I'm pretty adamant about this. There will be a huge
amount of
>>>>> confusion
>>>>> if we don't make this separation. Wildfly/JBoss and
Keycloak
are hard
>>>>> enough to configure as it is.
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>>
http://bill.burkecentral.com
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org <mailto:
keycloak-dev(a)lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>>
http://bill.burkecentral.com
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev