Difference between revisions of "DisableServerExtensions"
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
* '''Launchpad Entry''': [[NovaSpec]]:disable-server-extensions | * '''Launchpad Entry''': [[NovaSpec]]:disable-server-extensions | ||
− | * '''Created''': | + | * '''Created''': 30 Jul 2012 |
* '''Contributors''': Vishvananada Ishaya | * '''Contributors''': Vishvananada Ishaya | ||
Revision as of 19:23, 31 July 2012
- Launchpad Entry: NovaSpec:disable-server-extensions
- Created: 30 Jul 2012
- Contributors: Vishvananada Ishaya
Summary
There is currently no way to disable api extensions that modify post-data to servers. This blueprint proposes cleaning up the existing extensions so that they can be turned off.
Release Note
Server Extensions have been cleaned up so that functionality that is not in the OpenStack Compute API v2 spec can be disabled.
Rationale
Clouds are required to implement the core api spec to be api-compatible. There are a lot of extensions that are heavily used, but some cloud providers may not want to support them. Therefore there needs to be a way to disable them.
User stories
Assumptions
Design
Extending the extension mechanism to do this properly is probably more aligned with the novaplugin blueprint. In the short term, we need to take a simple approach that allows us to disable some functionality if an extension is not loaded.
Implementation
Existing Extensions
Right now the following non-spec data is handled in a server request:
- security_groups (related to SecurityGroups) <-rename?
- os:scheduler_hints (related to os-scheduler-hints)
- key_name (related to os-keypairs)
- config_drive (related to os-config_drive) <-remove _
- OS-DCF:disk_config (related to DiskConfig) <-rename?
- networks (related to os-networks)
- user_data (no extension)
- min_count/max_count (no extension)
- return_reservation_id (no extension part of min/max? appears unused?)
(note that some of these do not have an os: prefix. We likely have to skip adding a prefix for these because it will break compatibility.)
Plan of Attack
- consistently name the extensions
- add extension for user_data
- add extension for min_count/max_count
- add method for checking if extension is enabled
- add conditionals for each parameter for an extension
- sanitize out extra data passed in to the server entity
Other Concerns
I don't think server data is sanitized on import, so it is possible to pass data in that circumvents extensions. Therefore, extra fields should be sanitized out of server data.
Outstanding Questions
What needs to be done to make XML work properly for this?