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

Tue May 12 01:33:59 EDT 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150512/cd3c38d2/attachment-0001.html 