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

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?

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

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?

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)!

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(a)apache.org&gt; 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(a)apache.org&gt; > 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(a)apache.org&gt; >> wrote: >> >>> >>> >>> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; >>> 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(a)apache.org&gt; >>>> > wrote: >>>> > >>>> > > >>>> > > >>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx(a)qmx.me&gt; 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(a)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(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev