Difference between revisions of "DisableServerExtensions"
| Line 26: | Line 26: | ||
== Implementation == | == Implementation == | ||
| + | === Existing Extensions === | ||
Right now the following non-spec data is handled in a server request: | Right now the following non-spec data is handled in a server request: | ||
| Line 31: | Line 32: | ||
* os:scheduler_hints (related to os-scheduler-hints) | * os:scheduler_hints (related to os-scheduler-hints) | ||
* key_name (related to os-keypairs) | * key_name (related to os-keypairs) | ||
| − | * config_drive (related to os-config_drive) | + | * config_drive (related to os-config_drive) <-remove _ |
* OS-DCF:disk_config (related to [[DiskConfig]]) <-rename? | * OS-DCF:disk_config (related to [[DiskConfig]]) <-rename? | ||
* networks (related to os-networks) | * networks (related to os-networks) | ||
| Line 39: | Line 40: | ||
(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.) | (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 === | === 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. | 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? | ||
== Test/Demo Plan == | == Test/Demo Plan == | ||
| − | |||
| − | |||
== Unresolved issues == | == Unresolved issues == | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
---- | ---- | ||
[[Category:Spec]] | [[Category:Spec]] | ||
Revision as of 18:08, 31 July 2012
- Launchpad Entry: NovaSpec:disable-server-extensions
- Created: 28 Sep 2011
- 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?
