On Wed, May 13, 2015 at 10:20 AM, Matthias Wessendorf <matzew@apache.org> wrote:
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?
yup 

Now, a migration specific question: coming from UPS 1.0.3 to 1.1.0. _and_ 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
Sure, we can do it - as long as you agree with the potential data loss, I'm fine with it.
 

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?
Because this would be a PITA (dealing with raw jdbc, custom java code for migrating it, multiplied for 2 (pgsql & mysql))
 

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)!
Amen, brother!
 
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.






On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <matzew@apache.org> 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@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@apache.org> wrote:


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno@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@apache.org>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx@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@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--



--

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