The enablement of OpenShift.io features is controlled by Feature Flags

[qodfathr]

Goal

Ability for Product Management to control which features in production are visible to groups of users.

Description

This is the phase one implementation of feature flags for OSIO. This will allow Red Hat to continue to create experimental and innovative features without disrupting users in production. It will provide per-user controls so that each can choose their level of visibility into pre-production features. For this Epic, control is limited to the OpenShift.io UI -- in other words, the feature flags essentially control the visibility of UI elements.

Capabilities

• [x] Individual users can control whether they can see pre-production features #1668 #1669

  • Users are presented with the current acceptance screen
  • Users can select whether they want to view no pre-production features, only beta features, all experimental features

• [x] Clear indication that the user is in a preview area

• [x] Changing feature flags is done via a method that does not require rebuilding or redeploying (e.g. changing of JSON file) #1671

• [x] Feature flag settings: internal, experimental, beta, released

  • Internal will only show it to accounts with an @redhat.com email. It will have a notification on the screen: "This feature is open to Red Hat users only. You can manage pre-production features on your profile page." (banner will be red).
  • Experimental will be "This feature is experimental. You can manage pre-production features on your profile page." (banner will be yellow).
  • Beta notification will be "This feature is in beta. You can manage pre-production features on your profile page." (banner will be green).
  • Released makes the feature default for everyone.

Desired types of control

listed in priority order

• [x] Enable/Disable an entire Screen #1667 (as a reminder, Screens are the 2nd level of navigation; some current examples are Planner/Board and Create/Applications)
• [ ] Enable/Disable a capability on a screen #1672 #1673 e.g. The ‘Open in IDEA’ menu option of the pipeline kabob on the Create/Pipelines screen
• [ ] Enable/Disable a change to existing functionality (for those things which can safely be turned on/off. Not appropriate for changes which have a corresponding back-end schema change.) e.g. A rewrite of Planner’s Iteration UI, perhaps moving it from the Planner screen to a Configuration screen
• [ ] Enable/Disable a capability in a report e.g. The display of the ‘licensing’ analysis vector in the Stack Report
• [ ] Enable/Disable a capability in Che e.g. The PR UI e.g. Analytics integration e.g. Support for golang
• [ ] Enable/Disable an entire Screen Group. (as a reminder, Screen Groups are the top-level navigation areas; currently Analyze, Plan, Create)

For later:

• [ ] Users to have finer-grain control over which preview features they see e.g. Planner preview features but not Pipelines Release Candidate vs. Beta vs. Alpha etc.
• [ ] Reporting on experimental / preview features e.g. user in preview mode have 5% higher (or lower ;-) rate of exceptions
• [ ] Kill switch for badly behaving features
• [ ] Sunset old unused features
• [ ] Feature flags for non UI capabilities
  • Enable/Disable a capability in a pipeline e.g. The running of analytics in a build
  • Enable/Disable a capability in a part of a pipeline e.g. The ‘licensing’ analysis vector in analytics

Implementing Features

• [x] #1667
• [x] #1668
• [x] #1669
• [x] #1670
• [x] #1671
• [x] #1673
• [ ] https://github.com/fabric8-ui/fabric8-ux/issues/817
• [x] #1958
• [x] #2053
• [x] #2055
• [x] #2056
• [x] #2626

Impacted by

• [x] #2064
• [x] #2124 Unable to enable experimental features

Parent Fundamental

2036 OpenShift.io should be Testable in Production

[qodfathr]

@slemeur please see above, as Che is called out. Feel free to comment if you'd like to see any changes/additions.

[corinnekrych]

@qodfathr Our understanding of the requirements is that a logged-in user can opt in/out for internal/experimental/beta features. What should happen for anonymous users? Should they have access to no experimental feature, or as implemented today with Planner, access to all experimental features? Should we unified the behaviour and do not show an experimental feature to anonymous user.

[joshuawilson]

Since we store their choice to what they want to access on their profile they must be logged in to get past the experimental stage. Therefore, if they don't login then they can only see released content.

@qodfathr if you want it different then we need to rethink how we do things technically. I suppose they could access experimental areas but they would not store it as a setting. Still this would require a change.

[corinnekrych]

@catrobson @joshuawilson do we have an issue/epic for the UX flows for features toggles? One question that was asked by auth team cc @alexeykazakov @sbose78 @xcoulon is: for the admin flow, is it only the user that can select which toggle settings he is on? or could it be an admin user to define group of internal/experimental/beta users?

[catrobson]

We have a requirements gathering story to kick this off and gather information about this. We want to have a kick-off meeting with Eng, UX, PM to discuss these details together, and then we will build user flows & wireframes.

https://github.com/fabric8-ui/fabric8-ux/issues/724

[qodfathr]

@corinnekrych @joshuawilson sorry that I missed the question from a few months ago. Joshua's response was and still is correct -- anonymous users only see "released" content.

[corinnekrych]

@qodfathr @joshuawilson @catrobson @xcoulon Could we close this one as an epic for G-train. We could open a new EPIC that hilghlights better what left to do:

• admin console for PM to set finer granularity for feature level, admin PM role, admin developer (internal feature)
• grouping of features
• component wrapper for finer granularity on the page: with or without dynamic loading, how do we display them (UX)
• etc... from that EPIC we can them create user stories. wdyt?

[qodfathr]

@corinnekrych when we move to the OSIO Planner we'll have a way to deal with multi-train "epics", but, to keep GitHub Issues clean and moving forward, I'm fine with this plan -- open a new Epic, xref it from here, and close this Epic.

[qodfathr]

@corinnekrych after some thought, I think it's best to just keep this issue open and complete it in Heather. Let's use it as motivation to get it done early in the train. :)

[qodfathr]

Question -- how do feature flags handle anonymous browsing?

PM has decided that anonymous browsing should be treated the same as a user who is set to the Released level of flags. Does the burden of making this determination lie with the consumer of the feature flag APIs, or do these APIs handle this use case automatically?

[corinnekrych]

@qodfathr this is how it is displayed atm: the fabric8-toggles-service api/features return a 401 so we don't get the information on each feature's level (therefore the grey - indetermined- banner). If we want a separate behavior it's worth opening a user story for it. we might need to revisit the endpoint or offer another endpoint. cc @xcoulon

[corinnekrych]

@qodfathr tracked in: https://github.com/openshiftio/openshift.io/issues/2091

[mceledonia]

Latest designs for feature flags - user opt-in and visual indicator are found here

[qodfathr]

@catrobson I'm still envisioning value in having a "release candidate" level for feature flags (maybe call it "production candidate" to match the current nomenclature?), but I'd appreciate a recommendation from UXD on that.

As a reminder, in this model the features at the RC level are production ready. The differences between RC and prod are (1) RC features can turn on at any time, whereas prod features follow a regular cadence (e.g. every 3 weeks) and (2) RC features might not have all of the docs yet published. But RC features would not have any on-screen visual indicator (just like prod does not). That will facilitate the creation of documentation and screen shots, as RC is otherwise indistinguishable from prod. (As opposed to a screenshot of a feature late in the beta cycle, which would end up have the 'beta' markings on the screen.)

I'd even consider RC being internal-only, but I personally don't think that's necessary - but, again, I seek UXD guidance.

[catrobson]

Thanks Todd. We'll update the designs to capture this - sorry this got lost in the revisions!

[corinnekrych]

I've created:

• User consent screen revisited
• Display feature-flagged components

@joshuawilson @qodfathr @catrobson @xcoulon to be able to work on Display feature-flagged components, we really need concrete use-cases. Something better than feature1 is beta feature2 is experimental etc... Identifying several components under experiment in either fabric8-ui or fabric8-planner will really help. Besides without use cases, there is nothing to demo possible in prod.

From the discussion, I understand the UX design is still under discussion (so dev is waiting until design is agreed) but pls consider taking real use cases.

cc @aslakknutsen

[qodfathr]

@corinnekrych we can get you some real examples. @joshuawilson @xcoulon @aslakknutsen we likely need to become more prescriptive with all new development to ensure that it's backed by new feature flags.

[corinnekrych]

@qodfathr @xcoulon @aslakknutsen @joshuawilson @mceledonia let's identify use-case for next UX review, replacing feature1, feature2 with real components.