<div dir="ltr">From Stian on IRC<div><br></div><div>
<p class=""><span class="">[07:20:00] </span><span class=""><b><matzew></b></span><span class=""> </span><span class=""><b>stianst</b></span><span class=""> DB migration from 1.0.5.Final to KC 1.2.0.CR1 is not working, like you hinted last night, right ? /cc </span><span class=""><b>abstractj</b></span></p>
<p class=""><span class="">[07:20:21] </span><span class=""><b><stianst></b></span><span class=""> matzew: yep, there's no chance it'll work</span></p></div><div>
<p class=""><br></p><p class=""><br></p><p class="">So, what does that mean? It means no DB migration support for KC database. Perhaps that is OK, </p><p class="">I can't wrap my head around this now.</p><p class=""><br></p><p class="">But the migration for our own schema should be possible w/ the help of the migration tool - let's focus on that for now</p><p class=""><br></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry if I'm late for this discussion.<br>
<span><br>
On 2015-05-07, Matthias Wessendorf wrote:<br>
> How about the following, not optimal, proposal:<br>
><br>
> * get back to one data-source<br>
<br>
</span>I'm not against about it, if it's for the benefit of the project.<br>
<span><br>
> * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above<br>
> item harder)<br>
<br>
</span>I don't get why master must be reverted to 1.1.0 final. I think stable<br>
release of KC must go in 1.0.x series of UPS, but on master, we must<br>
stick with the latest greatest release of KC. Because is the only way to<br>
work closely with KC team.<br></blockquote><div><br></div></span><div>does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?</div><div>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 :-) </div><div><br></div><div><br></div><div>Or, we just do NOT support any KC db migration, just ours - that's fine w/ me...</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
><br>
> I understand that a separation of the two is needed on the longer run - it<br>
> would be good if that's something on our agenda post 1.1.0 e.g. for 1.2.0<br>
><br>
> I think the above is a 'work around', which I could live with and buys us<br>
> time to truly think about a perfect separation.<br>
<br>
</span>My 2 cents here and my humble opinion is the fact that we don't need perfection,<br>
only the correct. Today, split Keycloak and UPS would the most<br>
correct thing to do. I'm not saying what we're doing here is dead wrong, but<br>
sooner or later the problem will hit us anyway.<br>
<br>
So maybe we should attack the problem now?<br>
<div><div><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>><br>
> wrote:<br>
><br>
> ><br>
> ><br>
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <<a href="mailto:qmx@qmx.me" target="_blank">qmx@qmx.me</a>> wrote:<br>
> ><br>
> >> Howdy y'all!<br>
> >><br>
> >> I'm revisiting migration strategies for UPS master, and we have a tough<br>
> >> situation to deal with.<br>
> >><br>
> >> Since we have moved keycloak to its own DataSource, there are KC<br>
> >> leftovers at UPS database which need to be cleaned up.<br>
> >><br>
> >> 1) Any suggestions on how to provide a migration path?<br>
> >> Since the tables are intertwined with UPS tables, it's not a matter of<br>
> >> doing a db dump/restore...<br>
> >><br>
> ><br>
> > how are they intertwined? Is UPS stuff stored in KC tables, or vice versa?<br>
> ><br>
> ><br>
> >> 2) How to ensure we can safely get rid of the leftover tables on UPS<br>
> >> DataSource?<br>
> >> I can easily provide migrations which just nuke the tables from the<br>
> >> face of the earth,<br>
> >><br>
> ><br>
> > that's good, but<br>
> ><br>
> ><br>
> >> but how to do this without data loss?<br>
> >><br>
> ><br>
> > I don't know :-) I wonder if we just can not move the data to a new<br>
> > datasource.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> >><br>
> >> Thoughts?<br>
> >><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Matthias Wessendorf<br>
> ><br>
> > blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> > sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> > twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
--<br>
<br>
</div></div>abstractj<br>
PGP: 0x84DC9914<br>
<div><div>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br><div>Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Matthias Wessendorf <br><br>blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a></div>
</div>