Open Stack

On Oct 24, 2013 11:38 PM, "Michael Still" <mikal at stillhq.com> wrote:
>
> On Fri, Oct 25, 2013 at 9:07 AM, Boris Pavlovic <boris at pavlovic.me> wrote:
> > Johannes,
> >
> > +1, purging should help here a lot.
>
> Sure, but my point is more:
>
>  - pruning isn't done by the system automatically, so we have to
> assume it never happens

I thought this was done to preserve records , as at the time ceilometer
didn't exist, and we wanted to make sure nova kept records by default.  And
we couldn't assume deployers were using db snapshots either. But once we
can say don't use nova DB for records, we can start automatically pruning
or optionally move over to hard delete.

I think there have been some implicit assumptions that all large
deployments know about this and manually prune or do something similar.

IMHO OpenStack in general needs a stronger record keeping story. As these
issues will (or do?) affect other services besides nova.

>
>  - we need to have a clearer consensus about what we think the maximum
> size of a nova deployment is. Are we really saying we don't support
> nova installs with a million instances? If so what is the maximum
> number of instances we're targeting? Having a top level size in mind
> isn't a bad thing, but I don't think we have one at the moment that we
> all agree on. Until that happens I'm going to continue targeting the
> largest databases people have told me about (plus a fudge factor).
>

Agreed, I am surprised that the 30 million entry DB people aren't pruning
somehow (so I assume). I wonder what that DB looks like with pruning.

> Michael
>
> --
> Rackspace Australia
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131025/353da990/attachment.html>