yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #41590
[Bug 1450940] Re: Refactor angular features enablement
** Changed in: horizon
Importance: Medium => Wishlist
** Changed in: horizon
Status: In Progress => Invalid
** Changed in: horizon
Assignee: Travis Tripp (travis-tripp) => (unassigned)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1450940
Title:
Refactor angular features enablement
Status in OpenStack Dashboard (Horizon):
Invalid
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1450940/+subscriptions
References