Refactor angular features enablement

Bug #1450940 reported by Travis Tripp on 2015-05-01
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Wishlist
Unassigned

Bug Description

LAUNCH_INSTANCE_NG_ENABLED & LAUNCH_INSTANCE_LEGACY_ENABLED
were added as new feature toggles in Kilo. We added multiple
spots on the python code that looks it up in a rather non-declarative
and non abstract way. We also just created a generic settings
angular service. This worked, but now we are thinking about
ways to standardize on this concept so that a common features
API on the Python side and angular side can be used abstract
looking up whether or not a feature is enabled. This provides
better abstraction and isolation between code that needs to know
if a feature is enabled or not and will allow more standardization
or logic in the future to determine whether or not a feature is enabled
with less likelihood of having to rewrite all existing code.

This is not intended to replace all existing settings in settings.py.

For example, current feature lookup on python side looks like this:

getattr(settings, 'LAUNCH_INSTANCE_LEGACY_ENABLED', True):

It would be better if we can simply say:

features.enabled('LAUNCH_INSTANCE_LEGACY', True)

Similarly on the angular side, you inject a settings service which has a pretty direct binding to the underlying python settings. Using and injecting a Feature service will allow us to use different methodologies in the future without having to change code. It will provide an abstraction layer.

To support standard settings service lookups, we will create a common features area under local_settings.py with the following structure:

FEATURE = {
    'LAUNCH_INSTANCE_NG': {
        'enabled': True,
    },
    'IDENTITY_USERS_TABLE_NG': {
        'enabled': True,
    }
}

This will enable simple lookup using a python utility or the angular settings service via a helper function.

This structure will enable much richer future fields to be added to describe the feature, its status, etc. e.g.:

FEATURES = {
    'LAUNCH_INSTANCE_NG': {
        'enabled': True,
        'description': 'super cool next gen launch instance',
        'status': 'beta'
    }
}

Initially, all that will determine if a feature is enabled will be the 'enabled' toggle. But in the future other fields or logic could be used without disturbing the code the uses the feature utils or featureService.

Changed in horizon:
assignee: nobody → Travis Tripp (travis-tripp)
description: updated

Fix proposed to branch: master
Review: https://review.openstack.org/179545

Changed in horizon:
status: New → In Progress
summary: - Move LAUNCH_INSTANCE_NG_ENABLED under common feature settings
+ Refactor angular features enablement
description: updated
Changed in horizon:
importance: Undecided → High
importance: High → Medium
description: updated
description: updated

Change abandoned by Travis Tripp (<email address hidden>) on branch: master
Review: https://review.openstack.org/179545

Changed in horizon:
importance: Medium → Wishlist
status: In Progress → Invalid
assignee: Travis Tripp (travis-tripp) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers