[keycloak-dev] Is it ok to support multiple managementUrls per application?

[Marek Posolda]

That's an option, but it would require that adapters would need to be 
aware of that and have support for jgroups/jms/infinispan ? Perhaps we 
can add sender/receiver SPI for that?

I know that having more managementUrls is not ideal solution and have 
many pitfalls as you mentioned:-\ However it doesn't have any further 
requirements on adapters (like being capable to receive jgroups/jms 
message). I think that many adapters might want to rely just on 
sticky-session provided by LB and don't want to have any additional 
communication among each other. So setup with more managementUrls might 
be still the best option for some deployments.

I am not sure tbh. Maybe for Beta-1 we can keep just multiple 
managementUrls and add sender/receiver SPI with possibility for 
jgroups/jms to Beta-2 ?

Marek

On 14.10.2014 19:49, Stian Thorgersen wrote:
> Would it be an idea to add more options on how admin events are delivered? We could for example add jgroups and jms. Either of those would be more efficient in a cluster and wouldn't require managing nodes.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 13 October, 2014 9:59:26 AM
>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls	per	application?
>>
>> Adding multiple management URLs to an application is going to be cumbersome
>> to maintain. It would require manually registering/unregistering nodes with
>> Keycloak.
>>
>> WildFly for example automatically detects cluster members, and add/removes
>> nodes to Apache. Introducing KC would then add a cumbersome manual
>> registration process. Even worse with automatic provisioning of nodes it
>> simply won't work (think cloud).
>>
>> Another issue is that we'd have to deal with making sure new nodes and
>> temporarily unavailable nodes retrieve the updates as well. We probably need
>> to improve on this in either case, a single node can also be temporarily
>> unavailable (and miss notBefore or logout notifications), but doing it for a
>> cluster is harder than for a single node.
>>
>> There's also the use-case when KC and applications are on different subnets
>> where only the load balancer is visible to Keycloak.
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 10 October, 2014 5:08:44 PM
>>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls per
>>> 	application?
>>>
>>> On 10.10.2014 17:07, Marek Posolda wrote:
>>>> The problem I am looking at is sending "Push NotBefore" from keycloak
>>>> to adapters in cluster. Basically the info about push notBefore should
>>>> be propagated to all cluster nodes where application is deployed.
>>>>
>>>> ATM I am seeing 2 possibilities:
>>>>
>>>> a) More managementUrls per ApplicationModel. People would need to
>>>> configure all nodes where adapter is deployed . Then Keycloak (
>>>> ResourceAdminManager ) will be able to send "global" events like
>>>> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
>>>> be sent just to single node like now .
>>>>
>>>> b) Ensure that notBefore can be replicated on adapters side. I don't
>>>> like this tbh. It requires adapters to be in replicated cluster, which
>>>> may not be an option for many deployments, who want to rely just on
>>>> sticky session.
>>>>
>>>> Any of those is not super-ideal, but I don't have better idea to
>>>> ensure cluster-safe propagation of NotBefore and global logout to all
>>>> cluster nodes.
>>>>
>>>> Better ideas?
>>>>
>>>> I have (b) already prototyped and working, but wanted to have ack from
>>>> you before go further, cleanup, start changing admin console etc.
>>> oops, sorry. I have (a) working (model change to support multiple
>>> managementUrls)
>>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>