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

[Bruno Oliveira]

On 2015-05-12, Matthias Wessendorf 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

+1 Thanks for the heads up

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

> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914