On 21/11/16 23:26, Menno Smits wrote: > On 18 November 2016 at 05:07, Nate Finch <nate.fi...@canonical.com > <mailto:nate.fi...@canonical.com>>wrote: > > Resources are also stored in mongo and can be unlimited in size > (not much different than fat charms, except that at least they're > only pulled down on demand). > > We should let admins configure their max log size... our defaults > may not be what they like, but I bet that's not really the issue, > since we cap them smallish (the logs stored in mongo are capped, > right?) > > Do we still store all logs from all machines on the controller? > Are they capped? That has been a problem in the past with large > models. > > > All logs for all agents for all models are stored in mongodb on the > controller. They are pruned every 5 minutes to limit the space used by > logs. Logs older than 3 days are always removed. The logs stored for > all models is limited to 4GB with logs being removed fairly so that > logs for a busy model don't cause logs for a quiet model to be > prematurely removed. > > The 3 day and 4GB limits are currently fixed but have been implemented > in such a way to allow them to become configuration options without > too much fuss.
OK, that sounds like a reasonable position for logs. "Allow n GB per model" is a simple way for people to think about the space allocation on the controller. For resources, it makes sense that we can fail cleanly and clearly if space available falls below an agreed threshold (as a percentage of the volume on which the resources are stored). For the controller as a whole, we might move into read-only mode in the event storage falls below a similar threshold. Do we have other classes of content that can grow materially? Finally, is it worth adding a field to the responses for common API calls (status etc) that includes warnings about total controller health? For example, when I type status on a model it might be useful to be told that space is running low. These could be aimed at being human-readable, mainly. Mark
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
