Open Stack

+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 <sigmavirus24 at gmail.com> wrote:
>
> On Jul 2, 2016 10:37 AM, "Dan Smith" <dms at danplanet.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>