[aerogear-dev] Dealing with UPS Keycloak data post-datasource-split

Wed May 13 09:48:31 EDT 2015

On Wed, May 13, 2015 at 3:30 PM, Douglas Campos <qmx at qmx.me> wrote:

>
>
> On Wed, May 13, 2015 at 10:20 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> a few questions:
>> - are we all still OK w/ going w/ 1.2.0 for our own 1.1.0 release?
>> - are we all still OK to keep KC data in a separate schema?
>>
> yup
>
> Now, a migration specific question: coming from UPS 1.0.3 to 1.1.0. _and_
>> going w/ a separate KC schema means:
>>
>> * this equal to a new/fresh install of the Keycloak server
>> * the admin would be back to the default password
>> * we can remove the KC tables from our own schema
>>
> Sure, we can do it - as long as you agree with the potential data loss,
> I'm fine with it.
>

yeah, not ideal, but... I am fine w/ it too.

>
>
>>
>> Now, before just removing the KC tables, I wonder why we can not just
>> 'raw copy' them to a different schema and have the KC build-in migration
>> handle its data?
>>
> Because this would be a PITA (dealing with raw jdbc, custom java code for
> migrating it, multiplied for 2 (pgsql & mysql))
>

ok, fair point

>
>
>>
>> If that's really not possible, ok. I am fine than with not having a
>> proper KC migration story, when coming from 1.0.3 to 1.1.0 (yes, it will be
>> documented)...
>> I also noticed  that Keycloak does not support user export/import atm.
>>
>> Moving forward, the next logical steps are an even stronger isolation
>> (yes, we know that since a while)!
>>
> Amen, brother!
>
>
>> Best would be that we no longer need to distribute our own custom
>> auth-server.war file. A few thoughts around that are captured in [1]. But
>> that's something we won't be doing for 1.1.0 time frame of UPS.
>>
>>
>> [1] https://issues.jboss.org/browse/AGPUSH-1047
>>
>>
>>
>>
>> On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> I think this means:
>>> * go w/ KC 1.2.0
>>> * keep the separate KC datasource
>>>
>>> For migration: I will write some text for KC db part: e.g. do some
>>> export/import before getting on to UPS-1.1.0. IMO that's good enough...
>>>
>>> On Tue, May 12, 2015 at 7:24 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> From Stian on IRC
>>>>
>>>> [07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
>>>> 1.2.0.CR1 is not working, like you hinted last night, right ? /cc
>>>> *abstractj*
>>>>
>>>> [07:20:21] *<stianst>* matzew: yep, there's no chance it'll work
>>>>
>>>>
>>>>
>>>> So, what does that mean? It means no DB migration support for KC
>>>> database. Perhaps that is OK,
>>>>
>>>> I can't wrap my head around this now.
>>>>
>>>>
>>>> But the migration for our own schema should be possible w/ the help of
>>>> the migration tool - let's focus on that for now
>>>>
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
>>>>> wrote:
>>>>>
>>>>>> Sorry if I'm late for this discussion.
>>>>>>
>>>>>> On 2015-05-07, Matthias Wessendorf wrote:
>>>>>> > How about the following, not optimal, proposal:
>>>>>> >
>>>>>> > * get back to one data-source
>>>>>>
>>>>>> I'm not against about it, if it's for the benefit of the project.
>>>>>>
>>>>>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>>>>>> above
>>>>>> > item harder)
>>>>>>
>>>>>> I don't get why master must be reverted to 1.1.0 final. I think stable
>>>>>> release of KC must go in 1.0.x series of UPS, but on master, we must
>>>>>> stick with the latest greatest release of KC. Because is the only way
>>>>>> to
>>>>>> work closely with KC team.
>>>>>>
>>>>>
>>>>> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
>>>>> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the
>>>>> end of the world to go back :-)
>>>>>
>>>>>
>>>>> Or, we just do NOT support any KC db migration, just ours - that's
>>>>> fine w/ me...
>>>>>
>>>>>
>>>>>>
>>>>>> >
>>>>>> > I understand that a separation of the two is needed on the longer
>>>>>> run - it
>>>>>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>>>>>> 1.2.0
>>>>>> >
>>>>>> > I think the above is a 'work around', which I could live with and
>>>>>> buys us
>>>>>> > time to truly think about a perfect separation.
>>>>>>
>>>>>> My 2 cents here and my humble opinion is the fact that we don't need
>>>>>> perfection,
>>>>>> only the correct. Today, split Keycloak and UPS would the most
>>>>>> correct thing to do. I'm not saying what we're doing here is dead
>>>>>> wrong, but
>>>>>> sooner or later the problem will hit us anyway.
>>>>>>
>>>>>> So maybe we should attack the problem now?
>>>>>>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org>
>>>>>> > wrote:
>>>>>> >
>>>>>> > >
>>>>>> > >
>>>>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me>
>>>>>> wrote:
>>>>>> > >
>>>>>> > >> Howdy y'all!
>>>>>> > >>
>>>>>> > >> I'm revisiting migration strategies for UPS master, and we have
>>>>>> a tough
>>>>>> > >> situation to deal with.
>>>>>> > >>
>>>>>> > >> Since we have moved keycloak to its own DataSource, there are KC
>>>>>> > >> leftovers at UPS database which need to be cleaned up.
>>>>>> > >>
>>>>>> > >> 1) Any suggestions on how to provide a migration path?
>>>>>> > >>   Since the tables are intertwined with UPS tables, it's not a
>>>>>> matter of
>>>>>> > >> doing a db dump/restore...
>>>>>> > >>
>>>>>> > >
>>>>>> > > how are they intertwined? Is UPS stuff stored in KC tables, or
>>>>>> vice versa?
>>>>>> > >
>>>>>> > >
>>>>>> > >> 2) How to ensure we can safely get rid of the leftover tables on
>>>>>> UPS
>>>>>> > >> DataSource?
>>>>>> > >>   I can easily provide migrations which just nuke the tables
>>>>>> from the
>>>>>> > >> face of the earth,
>>>>>> > >>
>>>>>> > >
>>>>>> > > that's good, but
>>>>>> > >
>>>>>> > >
>>>>>> > >> but how to do this without data loss?
>>>>>> > >>
>>>>>> > >
>>>>>> > > I don't know :-) I wonder if we just can not move the data to a
>>>>>> new
>>>>>> > > datasource.
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >>
>>>>>> > >> Thoughts?
>>>>>> > >>
>>>>>> > >> _______________________________________________
>>>>>> > >> aerogear-dev mailing list
>>>>>> > >> aerogear-dev at lists.jboss.org
>>>>>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>> > >>
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > > --
>>>>>> > > Matthias Wessendorf
>>>>>> > >
>>>>>> > > blog: http://matthiaswessendorf.wordpress.com/
>>>>>> > > sessions: http://www.slideshare.net/mwessendorf
>>>>>> > > twitter: http://twitter.com/mwessendorf
>>>>>> > >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Matthias Wessendorf
>>>>>> >
>>>>>> > blog: http://matthiaswessendorf.wordpress.com/
>>>>>> > sessions: http://www.slideshare.net/mwessendorf
>>>>>> > twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>> > _______________________________________________
>>>>>> > aerogear-dev mailing list
>>>>>> > aerogear-dev at lists.jboss.org
>>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> abstractj
>>>>>> PGP: 0x84DC9914
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>>> sessions: http://www.slideshare.net/mwessendorf
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> blog: http://matthiaswessendorf.wordpress.com/
>>>> sessions: http://www.slideshare.net/mwessendorf
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150513/d68f78b3/attachment.html 