Needs docs for feature flag priority

Bug #669942 reported by Deryck Hodge
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Low
Martin Pool

Bug Description

I added a feature flag today for timeout, and while I get the idea of "priority" in the abstract, I wasn't sure what value to choose. jml did a review of this for me and also had no idea what value to use. I went with 1, which seemed a nice default, and mthaddon got an OOPS because priority must be unique across all flags. This further complicates my understanding of this attribute of a feature flag. :-)

So we need some docs about what this attribute means, how it's used, and what values we should assign.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 669942] [NEW] Needs docs for feature flag priority

Its described in the docstrings and the wiki. Perhaps you'd like to
improve those on the wiki ? :)

Higher priority wins.

Gary Poster (gary)
Changed in launchpad-foundations:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Deryck Hodge (deryck) wrote :

Robert, I don't mind updating the docstrings or wiki. I don't get it, though. I've heard "higher priority wins" before and it's not enough to help me understand it. Currently, people are just incrementing the priority number with each new flag. So it's better to say "newest flag wins," but why do I care? Why are the flags fighting? What flexibility does this add? How should we design our flags with this priority in mind?

I could make educated guesses on those questions based on using them and talking to Martin, but I think it makes sense to document this better. It just came up again with Graham asking me today.

Cheers,
deryck

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 669942] Re: Needs docs for feature flag priority

On Fri, Nov 5, 2010 at 4:49 AM, Deryck Hodge <email address hidden> wrote:
> Robert, I don't mind updating the docstrings or wiki.  I don't get it,
> though.  I've heard "higher priority wins" before and it's not enough to
> help me understand it.  Currently, people are just incrementing the
> priority number with each new flag.  So it's better to say "newest flag
> wins," but why do I care?  Why are the flags fighting?  What flexibility
> does this add?  How should we design our flags with this priority in
> mind?

Great questions - and I wouldn't have thought to answer them all. So here goes.
We have scopes, rules and flags.
Flags are set from a rule.
The rule that determines the value of a flag is:
"The highest priority rule for that flag whose scope matches"

As an example consider two rules for timeouts:
hard_timeout team:admins 1 18000
hard_timeout default 0 15000

Asking for the flag 'hard_timeout' will cause the feature controller
to loop on these two rules - first the team:admins one, then the
default one. Any request for which the logged in user is an admin will
match the higher priority rule, all other requests will fall down to
the next rule.

Hope that helps.
-Rob

Revision history for this message
Deryck Hodge (deryck) wrote :

Makes perfect sense now, thanks! I'll update docstrings and the wiki page where appropriate tomorrow, and consider this bug closed.

Cheers,
deryck

Revision history for this message
Martin Pool (mbp) wrote :

I filed <https://bugs.launchpad.net/launchpad/+bug/719186> saying that making people assign nonoverlapping integers themselves is a bit crude. Maybe someone can add an ajaxy drag and drop interface or suggest something better.

Also <https://dev.launchpad.net/Foundations/FeatureFlags> now has developer-oriented docs including Robert's example; suggestions for what more to add would be welcome.

Changed in launchpad:
assignee: nobody → Martin Pool (mbp)
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.