+1 to #4 -- As an operator I have archive and audit requirements that proactive automated DB pruning would likely get in the way of. If we do produce pruning tools I think they should exist in the OPS repo and, as a rule, should not be part of the general deployment/upgrade framework.
On Sat, Jul 2, 2016 at 5:20 PM, Ian Cordasco <[email protected]> wrote: > > On Jul 2, 2016 10:37 AM, "Dan Smith" <[email protected]> wrote: >> >> > The question is whether we should do something like this: >> > >> > 1) As part of the normal execution of the service playbooks; >> > 2) As part of the automated major upgrade (i.e. The step is not >> > optional); >> > 3) As part of the manual major upgrade (i.e. The step is optional); >> > 4) Never. >> >> I am not an operator, but I would think that #4 is the right thing to >> do. If I want to purge the database, it's going to be based on billing >> reasons (or lack thereof) and be tied to another archival, audit, etc >> policy that the "business people" are involved with. Install and >> configuration of my services shouldn't really ever touch my data other >> than mechanical upgrade scripts and the like, IMHO. >> >> Purging the database only during upgrades is not sufficient for large >> installs, so why artificially tie it to that process? In Nova we don't >> do data migrations as part of schema updates anymore, so it's not like a >> purge is going to make the upgrade any faster... > > 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. > > I see no reason to over extend upgrades with something not inherently > necessary or appropriate for upgrades. > > -- > Ian > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
