Machines, services and units all now support recording status history. Two issues have come up:
1. https://bugs.launchpad.net/juju-core/+bug/1530840 For units, especially in steady state, status history is spammed with update-status hook invocations which can obscure the hooks we really care about 2. https://bugs.launchpad.net/juju-core/+bug/1557918 We now have the concept of recording a machine provisioning status. This is great because it gives observability to what is happening as a node is being allocated in the cloud. With LXD, this feature has been used to give visibility to progress of the image downloads (finally, yay). But what happens is that the machine status history gets filled with lots of "Downloading x%" type messages. We have a pruner which caps the history to 100 entries per entity. But we need a way to deal with the spam, and what is displayed when the user asks for juju status-history. Options to solve bug 1 A. Filter out duplicate status entries when presenting to the user. eg say "update-status (x43)". This still allows the circular buffer for that entity to fill with "spam" though. We could make the circular buffer size much larger. But there's still the issue of UX where a user ask for the X most recent entries. What do we give them? The X most recent de-duped entries? B. If the we go to record history and the current previous entry is the same as what we are about to record, just update the timestamp. For update status, my view is we don't really care how many times the hook was run, but rather when was the last time it ran. Options to solve bug 2 A. Allow a flag when setting status to say "this status value is transient" and so it is recorded in status but not logged in history. B. Do not record machine provisioning status in history. It could be argued this info is more or less transient and once the machine comes up, we don't care so much about it anymore. It was introduced to give observability to machine allocation. Any other options? Opinions on preferred solutions? I really want to get this fixed before Juju 2.0 -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
