<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 6:30 AM, Boris Pavlovic <span dir="ltr"><<a href="mailto:boris@pavlovic.me" target="_blank">boris@pavlovic.me</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">Hi Mark, Nikola, David<div><br></div><div>Our work is not just in case of unifying. It improves the situation in all project (not only in Nova). </div>
<div><br></div><div><br></div><div>I would like to say my opinion about DB Archiving also ;) </div>
<div><br></div><div>Let start from the problem, abstract solution, current solution, and why this solution is ok. </div><div><br></div><div>*) Problem.</div><div>Records from DB are not deleted at all, so our DB will die. </div>
<div>*) Abstract solution</div><div>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. </div>
<div>*) Current solution</div><div>1) Create shadow tables</div><div>2) Simple utils that move from table to shadow table deleted records</div><div><br></div><div>*) Problems in current solution. </div>
<div>If we just move deleted records to shadow table we have to do all joins (like in Nikola's migration). </div><div><br></div><div>So the problem is not in approach of shadow tables, problem is in current utils that are not enough smart.<br>
</div><div>And in oslo there is only code (that allows to create_shadow table and that check that shadow tables and main are synced) </div><div><br></div><div>And one more nit such migrations (as made Nikola) are pretty rare. <br>
</div><div><br></div><div>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.</div><div>More than we are ready to improve it. <br>
</div><div><br></div><div><br></div><div>Best regards,</div><div>Boris Pavlovic</div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br>
</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 9, 2013 at 3:05 PM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mon, 2013-07-08 at 14:15 +0200, Nikola Ðipanov wrote:<br>
> On 05/07/13 14:26, Boris Pavlovic wrote:<br>
> > Hi all,<br>
> ><br>
> > I would like to explain very high level steps of our work:<br>
> > 1) Sync work with DB in all projects (We have what we have, let it be in<br>
> > one place)<br>
> > 2) Refactor work with DB in one place (not independently in all projects)<br>
> ><br>
> > So I understand that our code around DB is not ideal, but let it be in<br>
> > one place at first.<br>
> ><br>
><br>
> This is fine in principle, however I don't think we should push it<br>
> without considering the details (where the devil is apparently).<br>
> I am arguing that DB archiving should be re-done and is broken<br>
> conceptually (example below), and I think it would be suboptimal (to say<br>
> the least) to get it everywhere first and then fix it.<br>
><br>
> Just saying a hand-wavy "yeah, but once it's in Oslo we can fix it" is<br>
> wrong - especially for functionality that is younger than the time it<br>
> will likely take it to 'graduate' Oslo.<br>
<br>
</div>I'm not following this DB archiving debate closely enough to take a<br>
position either way, but ....<br>
<br>
I think what you're really arguing is that no other project should adopt<br>
this approach to DB archiving. I'm fine with saying that it shouldn't<br>
move into oslo-incubator if it will only be used in Nova.<br>
<br>
So - the debate to have is which projects are proposing to adopt this DB<br>
archiving strategy and whether it makes sense for them to adopt it as is<br>
and fix it up later, or adopt an entirely different approach.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">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.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace">Thanks,<br>John<br></div><br></div></div>