Open Stack

Hi Mark, Nikola, David

Our work is not just in case of unifying. It improves the situation in all
project (not only in Nova).


I would like to say my opinion about DB Archiving also ;)

Let start from the problem, abstract solution, current solution, and why
this solution is ok.

*) Problem.
Records from DB are not deleted at all, so our DB will die.
*) Abstract solution
We should somehow remove old records, I see only one solution, create
shadow tables and have a utilities that are smart and could remove data in
such way, that shadow and main table are absolutly independent.
*) Current solution
1) Create shadow tables
2) Simple utils that move from table to shadow table deleted records

*) Problems in current solution.
If we just move deleted records to shadow table we have to do all joins
(like in Nikola's migration).

So the problem is not in approach of shadow tables, problem is in current
utils that are not enough smart.
And in oslo there is only code (that allows to create_shadow table and that
check that shadow tables and main are synced)

And one more nit such migrations (as made Nikola) are pretty rare.

So I don't see any reason to block this DB Archiving code in oslo and block
this approach. It could be improved not replaced.
More than we are ready to improve it.


Best regards,
Boris Pavlovic












On Tue, Jul 9, 2013 at 3:05 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Mon, 2013-07-08 at 14:15 +0200, Nikola Đipanov wrote:
> > On 05/07/13 14:26, Boris Pavlovic wrote:
> > > Hi all,
> > >
> > > I would like to explain very high level steps of our work:
> > > 1) Sync work with DB in all projects (We have what we have, let it be
> in
> > > one place)
> > > 2) Refactor work with DB in one place (not independently in all
> projects)
> > >
> > > So I understand that our code around DB is not ideal, but let it be in
> > > one place at first.
> > >
> >
> > This is fine in principle, however I don't think we should push it
> > without considering the details (where the devil is apparently).
> > I am arguing that DB archiving should be re-done and is broken
> > conceptually (example below), and I think it would be suboptimal (to say
> > the least) to get it everywhere first and then fix it.
> >
> > Just saying a hand-wavy "yeah, but once it's in Oslo we can fix it" is
> > wrong - especially for functionality that is younger than the time it
> > will likely take it to 'graduate' Oslo.
>
> I'm not following this DB archiving debate closely enough to take a
> position either way, but ....
>
> I think what you're really arguing is that no other project should adopt
> this approach to DB archiving. I'm fine with saying that it shouldn't
> move into oslo-incubator if it will only be used in Nova.
>
> So - the debate to have is which projects are proposing to adopt this DB
> archiving strategy and whether it makes sense for them to adopt it as is
> and fix it up later, or adopt an entirely different approach.
>
> Cheers,
> Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130709/c2cb8109/attachment.html>