Open Stack

On Tue, Jul 9, 2013 at 6:30 AM, Boris Pavlovic <boris at pavlovic.me> wrote:

> 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.
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Given that Cinder doesn't have anybody actively engaged in this other than
what's being proposed and worked on by Boris and folks, we'd be a willing
candidate for most of these changes, particularly if they're accepted in
Nova to begin with.

The question of having it in oslo-incubator or not, I think ultimately
that's likely to be the best thing, but as is evident by this thread it
seems there are a number of things that are going to have to be sorted
before that happens, and I'm not convinced that "move things to OSLO first
then fix" is the right answer.  In my opinion things should be pretty solid
before they go into the OSLO repo, but that's just my 2 cents.

AS is evident by the approval of the BP's in Cinder and the reviews on the
patches that have been submitted thus far Cinder is fine going the
direction/implementations that have been proposed by Boris.  I would like
to see the debate around the archiving strategy and use of alembic settled,
but regardless on the Cinder side I would like to move forward and make
progress and as there's no other real effort to move forward with improving
the DB code in Cinder (which I think is needed and very valuable) I'm fine
with most of what's being proposed.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/1dce79b1/attachment.html>