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

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