Quantcast

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

classic Classic list List threaded Threaded
23 messages Options
12
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator
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... 
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, but how to do this without data loss?

Thoughts?

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
How about the following, not optimal, proposal:

* get back to one data-source
* stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes above item harder)

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.






On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator
In reply to this post by Matthias Wessendorf


On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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?

UPS tables live alongside KC tables on the same schema/database

 
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.

We can, but you know how risky data migration is :) 



 

Thoughts?

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Thursday, May 7, 2015, Douglas Campos <[hidden email]> wrote:


On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;matzew@apache.org&#39;);" target="_blank">matzew@...> wrote:


On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;qmx@qmx.me&#39;);" target="_blank">qmx@...> 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?

UPS tables live alongside KC tables on the same schema/database

 
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.

We can, but you know how risky data migration is :) 

back to one schema, for 1.1.0 and do clean separation on 1.2.0?
 



 

Thoughts?

_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Erik Jan de Wit
Even though keycloak and UPS used to share the schema I'm pretty sure
that no data from UPS has ended up in Keycloak and visa versa. Because
there is no direct hibernate keycloak class usage in UPS, therefore
there is no way for UPS to store data in keycloak tables.

So I propose to nuke the keycloak tables that are left over in the UPS schema.

On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <[hidden email]> wrote:

>
>
> On Thursday, May 7, 2015, Douglas Campos <[hidden email]> wrote:
>>
>>
>>
>> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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?
>>
>>
>> UPS tables live alongside KC tables on the same schema/database
>>
>>>
>>>>
>>>> 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.
>>
>>
>> We can, but you know how risky data migration is :)
>
>
> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> 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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator


On Thu, May 7, 2015 at 4:58 AM, Erik Jan de Wit <[hidden email]> wrote:
Even though keycloak and UPS used to share the schema I'm pretty sure
that no data from UPS has ended up in Keycloak and visa versa. Because
there is no direct hibernate keycloak class usage in UPS, therefore
there is no way for UPS to store data in keycloak tables.

So I propose to nuke the keycloak tables that are left over in the UPS schema.

Sure, what about the potential user data that might be still living there? That's exactly why I'm bringing this to ag-dev :)
 

On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <[hidden email]> wrote:
>
>
> On Thursday, May 7, 2015, Douglas Campos <[hidden email]> wrote:
>>
>>
>>
>> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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?
>>
>>
>> UPS tables live alongside KC tables on the same schema/database
>>
>>>
>>>>
>>>> 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.
>>
>>
>> We can, but you know how risky data migration is :)
>
>
> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> 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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
back to one schema, for 1.1.0 and do clean separation on 1.2.0?


On Thursday, May 7, 2015, Douglas Campos <[hidden email]> wrote:


On Thu, May 7, 2015 at 4:58 AM, Erik Jan de Wit <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;edewit@redhat.com&#39;);" target="_blank">edewit@...> wrote:
Even though keycloak and UPS used to share the schema I'm pretty sure
that no data from UPS has ended up in Keycloak and visa versa. Because
there is no direct hibernate keycloak class usage in UPS, therefore
there is no way for UPS to store data in keycloak tables.

So I propose to nuke the keycloak tables that are left over in the UPS schema.

Sure, what about the potential user data that might be still living there? That's exactly why I'm bringing this to ag-dev :)
 

On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;matzew@apache.org&#39;);" target="_blank">matzew@...> wrote:
>
>
> On Thursday, May 7, 2015, Douglas Campos <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;qmx@qmx.me&#39;);" target="_blank">qmx@...> wrote:
>>
>>
>>
>> On Wed, May 6, 2015 at 10:26 PM, Matthias Wessendorf <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;matzew@apache.org&#39;);" target="_blank">matzew@...>
>> wrote:
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;qmx@qmx.me&#39;);" target="_blank">qmx@...> 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?
>>
>>
>> UPS tables live alongside KC tables on the same schema/database
>>
>>>
>>>>
>>>> 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.
>>
>>
>> We can, but you know how risky data migration is :)
>
>
> back to one schema, for 1.1.0 and do clean separation on 1.2.0?
>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
>>>> 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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>
>
> --
> Sent from Gmail Mobile
>
> _______________________________________________
> aerogear-dev mailing list
> <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Cheers,
       Erik Jan
_______________________________________________
aerogear-dev mailing list
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;aerogear-dev@lists.jboss.org&#39;);" target="_blank">aerogear-dev@...
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Sent from Gmail Mobile

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator
In reply to this post by Matthias Wessendorf


On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <[hidden email]> wrote:

back to one schema, for 1.1.0 and do clean separation on 1.2.0?

Worksforme(tm)

+1


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
Hi Doug,



On Fri, May 8, 2015 at 6:08 AM, Douglas Campos <[hidden email]> wrote:


On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <[hidden email]> wrote:

back to one schema, for 1.1.0 and do clean separation on 1.2.0?

Worksforme(tm)

+1

ok, cool - I'd say - let's do that.

So, since the KC part (e.g. new Keycloak versions), is covered by themselves, something like this [1] is not a huge issue, right? At least that's my understanding/assumption.

Related, we already have a vage epic to cover the separation, I have moved that to 1.2.0


 


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf


On Fri, May 8, 2015 at 12:08 PM, Matthias Wessendorf <[hidden email]> wrote:
Hi Doug,



On Fri, May 8, 2015 at 6:08 AM, Douglas Campos <[hidden email]> wrote:


On Thu, May 7, 2015 at 2:22 AM, Matthias Wessendorf <[hidden email]> wrote:

back to one schema, for 1.1.0 and do clean separation on 1.2.0?

Worksforme(tm)

+1

ok, cool - I'd say - let's do that.

So, since the KC part (e.g. new Keycloak versions), is covered by themselves, something like this [1] is not a huge issue, right? At least that's my understanding/assumption.

FYI - the KC version on master is now on 1.2.0.CR1 - but incase this has _negative_ effect for your migration work, please let us know. I think going back to an older version of KC is not a show stopper at all

-M 

Related, we already have a vage epic to cover the separation, I have moved that to 1.2.0


 


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bruno Oliveira
In reply to this post by Matthias Wessendorf
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.

>
> 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 <[hidden email]>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc
What about dumping only the KC tables (they have no relation with the UPS table)  restore them on the KC separate datasource, apply migration on this datasource and then  nuke the old KC  tables on the initial DB. And finally applying the UPS migration path ?


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <[hidden email]> 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.

>
> 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 <[hidden email]>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator


On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <[hidden email]> wrote:
What about dumping only the KC tables (they have no relation with the UPS table)  restore them on the KC separate datasource, apply migration on this datasource and then  nuke the old KC  tables on the initial DB. And finally applying the UPS migration path ?
Migrator tool has no support for moving data between databases. TL;DR is that this would be a PITA to get right. Better call would be KC having something like export/import in JSON or somesuch.
 


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <[hidden email]> 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.

>
> 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 <[hidden email]>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Sebastien Blanc

On Mon, May 11, 2015 at 11:29 PM, Douglas Campos <[hidden email]> wrote:


On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <[hidden email]> wrote:
What about dumping only the KC tables (they have no relation with the UPS table)  restore them on the KC separate datasource, apply migration on this datasource and then  nuke the old KC  tables on the initial DB. And finally applying the UPS migration path ?
Migrator tool has no support for moving data between databases. TL;DR is that this would be a PITA to get right. Better call would be KC having something like export/import in JSON or somesuch.
 


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <[hidden email]> 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.

>
> 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 <[hidden email]>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

qmx
Administrator


On Mon, May 11, 2015 at 6:32 PM, Sebastien Blanc <[hidden email]> wrote:
nope - the thing is moving data **between** datasources - this is only for updating the DB schema to one datasource
 


On Mon, May 11, 2015 at 11:29 PM, Douglas Campos <[hidden email]> wrote:


On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <[hidden email]> wrote:
What about dumping only the KC tables (they have no relation with the UPS table)  restore them on the KC separate datasource, apply migration on this datasource and then  nuke the old KC  tables on the initial DB. And finally applying the UPS migration path ?
Migrator tool has no support for moving data between databases. TL;DR is that this would be a PITA to get right. Better call would be KC having something like export/import in JSON or somesuch.
 


On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <[hidden email]> 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.

>
> 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 <[hidden email]>
> wrote:
>
> >
> >
> > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <[hidden email]> 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
> >> [hidden email]
> >> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
In reply to this post by Bruno Oliveira


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


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
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 <[hidden email]> wrote:


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


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
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 <[hidden email]> 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 <[hidden email]> wrote:


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


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Matthias Wessendorf
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?


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

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.






On Tue, May 12, 2015 at 7:33 AM, Matthias Wessendorf <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


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


--

abstractj
PGP: 0x84DC9914
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
12
Loading...