audit facility for feature flags

Big +1 from me, but I'm hoping Martin or someone else takes it on. If not, someone please kick me about this, because I agree that being able to revert easily and reliably is very important for the kind of power that the feature flags can wield.

The change_action method of FeatureControlView in lib/lp/services/features/browser/edit.py logs the new value. Is that enough?

On Wed, Jan 5, 2011 at 11:21 AM, Benji York <email address hidden> wrote:
> The change_action method of FeatureControlView in
> lib/lp/services/features/browser/edit.py logs the new value.  Is that
> enough?

I'd like to see an old->new I think, so that rolling back is easier.
Having it in the logs is sufficient for me (but we should note that it
*is* logged in the admin UI to avoid folk wondering about this).

-Rob

We ought to at least document where to find the results. It might be
nice if the logs were visible in the web ui. (Though doing so might
require a different approach to logging.)

--
Martin

I think the logging feature is pretty useless at this moment. I see the messages are logged in launchpad.log instead of their own log. It requires an admin with shell access and a lot of time to spare to locate lp.services.features entries. This needs to be its own log. The view will need to access it and present the content.

I propose that we store the diff of changes with a timestamp in the db (FeatureFlagActivity). We use a utility to get a list and append a diff (ActivityLog). I looked at the changes in dev and think the diff is more readable than old -> new.

The views only work with simple data. The models are hidden by utilities. I think we should continue this pattern. The rulesource classes do not work with individual FeatureFlags; the classes delete all of the flags and create new ones. Archiving individual rules requires reimplementation of a feature, and there is no plan to restore individual rules. so I conclude that we should archive a diff of the simple data and ensure that someone can copy and paste lines into the rules field.

On 16 February 2011 10:09, Curtis Hovey <email address hidden> wrote:
> I propose that we store the diff of changes with a timestamp in the db
> (FeatureFlagActivity). We use a utility to get a list and append a diff
> (ActivityLog). I looked at the changes in dev and think the diff is more
> readable than old -> new.
>
> The views only work with simple data. The models are hidden by
> utilities. I think we should continue this pattern. The rulesource
> classes do not work with individual FeatureFlags; the classes delete all
> of the flags and create new ones. Archiving individual rules requires
> reimplementation of a feature, and there is no plan to restore
> individual rules. so I conclude that we should archive a diff of the
> simple data and ensure that someone can copy and paste lines into the
> rules field.

That sounds reasonable to me.

Deleting and recreating everything when the rules are changed is not
really desired behaviour, just laziness. But it doesn't seem to
actually hurt much at the moment.

Fixed in db-stable r10244 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/10244>.