<p dir="ltr"><br>
On Jul 2, 2016 10:37 AM, "Dan Smith" <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
><br>
> > The question is whether we should do something like this:<br>
> ><br>
> > 1) As part of the normal execution of the service playbooks;<br>
> > 2) As part of the automated major upgrade (i.e. The step is not optional);<br>
> > 3) As part of the manual major upgrade (i.e. The step is optional);<br>
> > 4) Never.<br>
><br>
> I am not an operator, but I would think that #4 is the right thing to<br>
> do. If I want to purge the database, it's going to be based on billing<br>
> reasons (or lack thereof) and be tied to another archival, audit, etc<br>
> policy that the "business people" are involved with. Install and<br>
> configuration of my services shouldn't really ever touch my data other<br>
> than mechanical upgrade scripts and the like, IMHO.<br>
><br>
> Purging the database only during upgrades is not sufficient for large<br>
> installs, so why artificially tie it to that process? In Nova we don't<br>
> do data migrations as part of schema updates anymore, so it's not like a<br>
> purge is going to make the upgrade any faster...</p>
<p dir="ltr">I agree with this sentiment. If OSA feels like it must provide automation for purging databases, it should be in the ops repo mentioned earlier.</p>
<p dir="ltr">I see no reason to over extend upgrades with something not inherently necessary or appropriate for upgrades.</p>
<p dir="ltr">--<br>
Ian<br>
</p>