2:55 p.m.
In removing UserFederationModel I found that we have generic Migration
objects that use this api to upgrade LDAP. Specifically in
1.3.0
1.4.0
I vote we don't support migration anymore for anything older than 1.9.8
3:05 a.m.
I vote against that. There's a lot of users that are still on older
versions. We could ask them to upgrade to 1.9.8 first, but there's a chance
that could fail (we've seen this a few times) and as they can't upgrade to
the most recent version we can't fix it either.
On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com> wrote:
In removing UserFederationModel I found that we have generic
Migration
objects that use this api to upgrade LDAP. Specifically in
1.3.0
1.4.0
I vote we don't support migration anymore for anything older than 1.9.8
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:35 a.m.
Not sure I have time to port those migration scripts to Liquibase and
Mongo specific migration scripts. Its a day or more of work to
implement and manually test.
FYI, its actually any version < 1.9.0 as there are generic LDAP
migration scripts for 1.8.0 as well.
On 11/23/16 4:05 AM, Stian Thorgersen wrote:
I vote against that. There's a lot of users that are still on older
versions. We could ask them to upgrade to 1.9.8 first, but there's a
chance that could fail (we've seen this a few times) and as they can't
upgrade to the most recent version we can't fix it either.
On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
In removing UserFederationModel I found that we have generic Migration
objects that use this api to upgrade LDAP. Specifically in
1.3.0
1.4.0
I vote we don't support migration anymore for anything older than
1.9.8
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
11:13 a.m.
The generic migration is very cool, but there is problem that it has
hard dependency on the API, so you can't easily remove the stuff from
model API...
How about deprecate UserFederationProviderModel and deprecate all
UserFederationProviderModel CRUD methods on RealmModel? Or maybe even
remove those CRUD methods from RealmModel, but keep them just on JPA
RealmAdapter and Mongo RealmAdapter? The MigrateTo1_3_0 would need to
cast the RealmModel somehow to particular RealmAdapter though.
Marek
On 23/11/16 16:35, Bill Burke wrote:
Not sure I have time to port those migration scripts to Liquibase
and
Mongo specific migration scripts. Its a day or more of work to
implement and manually test.
FYI, its actually any version < 1.9.0 as there are generic LDAP
migration scripts for 1.8.0 as well.
On 11/23/16 4:05 AM, Stian Thorgersen wrote:
> I vote against that. There's a lot of users that are still on older
> versions. We could ask them to upgrade to 1.9.8 first, but there's a
> chance that could fail (we've seen this a few times) and as they can't
> upgrade to the most recent version we can't fix it either.
>
>
> On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> In removing UserFederationModel I found that we have generic Migration
> objects that use this api to upgrade LDAP. Specifically in
>
> 1.3.0
>
> 1.4.0
>
> I vote we don't support migration anymore for anything older than
> 1.9.8
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <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
2:24 p.m.
Good idea on keeping them on just the JPA/Mongo adapters...problem is,
we won't be able to remove the tables.
On 11/23/16 12:13 PM, Marek Posolda wrote:
The generic migration is very cool, but there is problem that it has
hard dependency on the API, so you can't easily remove the stuff from
model API...
How about deprecate UserFederationProviderModel and deprecate all
UserFederationProviderModel CRUD methods on RealmModel? Or maybe even
remove those CRUD methods from RealmModel, but keep them just on JPA
RealmAdapter and Mongo RealmAdapter? The MigrateTo1_3_0 would need to
cast the RealmModel somehow to particular RealmAdapter though.
Marek
On 23/11/16 16:35, Bill Burke wrote:
> Not sure I have time to port those migration scripts to Liquibase and
> Mongo specific migration scripts. Its a day or more of work to
> implement and manually test.
>
> FYI, its actually any version < 1.9.0 as there are generic LDAP
> migration scripts for 1.8.0 as well.
>
>
> On 11/23/16 4:05 AM, Stian Thorgersen wrote:
>> I vote against that. There's a lot of users that are still on older
>> versions. We could ask them to upgrade to 1.9.8 first, but there's a
>> chance that could fail (we've seen this a few times) and as they can't
>> upgrade to the most recent version we can't fix it either.
>>
>>
>> On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>> In removing UserFederationModel I found that we have generic
>> Migration
>> objects that use this api to upgrade LDAP. Specifically in
>>
>> 1.3.0
>>
>> 1.4.0
>>
>> I vote we don't support migration anymore for anything older than
>> 1.9.8
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <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
2:41 p.m.
This actually wouldn't work at all. The Liquibase/Mongo scripts would
already have converted the ldap provider to the new component
datamodel....HMMM.....I guess that means I can just modify the component
model! problem solved!
On 11/23/16 3:24 PM, Bill Burke wrote:
Good idea on keeping them on just the JPA/Mongo adapters...problem
is,
we won't be able to remove the tables.
On 11/23/16 12:13 PM, Marek Posolda wrote:
> The generic migration is very cool, but there is problem that it has
> hard dependency on the API, so you can't easily remove the stuff from
> model API...
>
> How about deprecate UserFederationProviderModel and deprecate all
> UserFederationProviderModel CRUD methods on RealmModel? Or maybe even
> remove those CRUD methods from RealmModel, but keep them just on JPA
> RealmAdapter and Mongo RealmAdapter? The MigrateTo1_3_0 would need to
> cast the RealmModel somehow to particular RealmAdapter though.
>
> Marek
>
> On 23/11/16 16:35, Bill Burke wrote:
>> Not sure I have time to port those migration scripts to Liquibase and
>> Mongo specific migration scripts. Its a day or more of work to
>> implement and manually test.
>>
>> FYI, its actually any version < 1.9.0 as there are generic LDAP
>> migration scripts for 1.8.0 as well.
>>
>>
>> On 11/23/16 4:05 AM, Stian Thorgersen wrote:
>>> I vote against that. There's a lot of users that are still on older
>>> versions. We could ask them to upgrade to 1.9.8 first, but there's a
>>> chance that could fail (we've seen this a few times) and as they
can't
>>> upgrade to the most recent version we can't fix it either.
>>>
>>>
>>> On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
>>> <mailto:bburke@redhat.com>> wrote:
>>>
>>> In removing UserFederationModel I found that we have generic
>>> Migration
>>> objects that use this api to upgrade LDAP. Specifically in
>>>
>>> 1.3.0
>>>
>>> 1.4.0
>>>
>>> I vote we don't support migration anymore for anything older than
>>> 1.9.8
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> <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
2:49 p.m.
Cool :-)
On 23/11/16 21:41, Bill Burke wrote:
This actually wouldn't work at all. The Liquibase/Mongo scripts
would
already have converted the ldap provider to the new component
datamodel....HMMM.....I guess that means I can just modify the component
model! problem solved!
On 11/23/16 3:24 PM, Bill Burke wrote:
> Good idea on keeping them on just the JPA/Mongo adapters...problem is,
> we won't be able to remove the tables.
>
>
> On 11/23/16 12:13 PM, Marek Posolda wrote:
>> The generic migration is very cool, but there is problem that it has
>> hard dependency on the API, so you can't easily remove the stuff from
>> model API...
>>
>> How about deprecate UserFederationProviderModel and deprecate all
>> UserFederationProviderModel CRUD methods on RealmModel? Or maybe even
>> remove those CRUD methods from RealmModel, but keep them just on JPA
>> RealmAdapter and Mongo RealmAdapter? The MigrateTo1_3_0 would need to
>> cast the RealmModel somehow to particular RealmAdapter though.
>>
>> Marek
>>
>> On 23/11/16 16:35, Bill Burke wrote:
>>> Not sure I have time to port those migration scripts to Liquibase and
>>> Mongo specific migration scripts. Its a day or more of work to
>>> implement and manually test.
>>>
>>> FYI, its actually any version < 1.9.0 as there are generic LDAP
>>> migration scripts for 1.8.0 as well.
>>>
>>>
>>> On 11/23/16 4:05 AM, Stian Thorgersen wrote:
>>>> I vote against that. There's a lot of users that are still on older
>>>> versions. We could ask them to upgrade to 1.9.8 first, but there's a
>>>> chance that could fail (we've seen this a few times) and as they
can't
>>>> upgrade to the most recent version we can't fix it either.
>>>>
>>>>
>>>> On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
>>>> <mailto:bburke@redhat.com>> wrote:
>>>>
>>>> In removing UserFederationModel I found that we have generic
>>>> Migration
>>>> objects that use this api to upgrade LDAP. Specifically in
>>>>
>>>> 1.3.0
>>>>
>>>> 1.4.0
>>>>
>>>> I vote we don't support migration anymore for anything older
than
>>>> 1.9.8
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> <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
2:47 p.m.
Yes, we won't . But I don't have any better idea.
It seems there are possibilities like:
1) Keep the userFederation model API and tables in DB. Just deprecate
the API
2) Converting generic migrations to Liquibase. This is lots of work, but
also it's problematic because of Liquibase checksums. For example if you
add new "customChange" to the existing jpa-changelog-1.3.0.xml the
migration will break for those, who are already on newer version than
1.3.0. This can be handled with liquibase preconditions, but
preconditions adds some additional mess and complexity...
3) Rewrite the old 1.3 generic migrations to use UserStorage SPI. This
sounds error prone and probably complex...
4) Migrate in the paths ( 1.2.0 to 1.9.8 , then 1.9.8 to 2.3), but that
has some other limitations Stian mentioned.
My vote is 4 or 1.
Marek
On 23/11/16 21:24, Bill Burke wrote:
Good idea on keeping them on just the JPA/Mongo adapters...problem
is,
we won't be able to remove the tables.
On 11/23/16 12:13 PM, Marek Posolda wrote:
> The generic migration is very cool, but there is problem that it has
> hard dependency on the API, so you can't easily remove the stuff from
> model API...
>
> How about deprecate UserFederationProviderModel and deprecate all
> UserFederationProviderModel CRUD methods on RealmModel? Or maybe even
> remove those CRUD methods from RealmModel, but keep them just on JPA
> RealmAdapter and Mongo RealmAdapter? The MigrateTo1_3_0 would need to
> cast the RealmModel somehow to particular RealmAdapter though.
>
> Marek
>
> On 23/11/16 16:35, Bill Burke wrote:
>> Not sure I have time to port those migration scripts to Liquibase and
>> Mongo specific migration scripts. Its a day or more of work to
>> implement and manually test.
>>
>> FYI, its actually any version < 1.9.0 as there are generic LDAP
>> migration scripts for 1.8.0 as well.
>>
>>
>> On 11/23/16 4:05 AM, Stian Thorgersen wrote:
>>> I vote against that. There's a lot of users that are still on older
>>> versions. We could ask them to upgrade to 1.9.8 first, but there's a
>>> chance that could fail (we've seen this a few times) and as they
can't
>>> upgrade to the most recent version we can't fix it either.
>>>
>>>
>>> On 22 Nov 2016 21:57, "Bill Burke" <bburke(a)redhat.com
>>> <mailto:bburke@redhat.com>> wrote:
>>>
>>> In removing UserFederationModel I found that we have generic
>>> Migration
>>> objects that use this api to upgrade LDAP. Specifically in
>>>
>>> 1.3.0
>>>
>>> 1.4.0
>>>
>>> I vote we don't support migration anymore for anything older than
>>> 1.9.8
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> <mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> <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
>
>
2955
days inactive
2956
days old
7 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen