Difference between revisions of "DisableServerExtensions"

Latest revision as of 23:31, 17 February 2013

• Launchpad Entry: NovaSpec:disable-server-extensions
• Created: 31 Jul 2012
• Contributors: Vishvananada Ishaya, Anne Gentle

<<TableOfContents(2)>>

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?)

up to date list with assignees here: http://etherpad.openstack.org/disable-server-extensions

(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?

Test/Demo Plan

Documentation

We are tracking missing extension documentation in the openstack-manuals project for those published to api.openstack.org, the only place for extension documentation currently available. I'm sure this is not exhaustive though so feel free to add doc bugs as needed.

• Live migration extension: https://bugs.launchpad.net/openstack-manuals/+bug/1022653
• os-hypervisor admin extension: https://bugs.launchpad.net/openstack-manuals/+bug/1027287 (Does this extension really work?)
• Reboot, soft reboot: https://bugs.launchpad.net/openstack-manuals/+bug/1017543
• os-quotas admin extension: https://bugs.launchpad.net/openstack-manuals/+bug/1029567
• os-aggregates missing info: https://bugs.launchpad.net/openstack-manuals/+bug/1015821
• Pause, suspend missing info: https://bugs.launchpad.net/openstack-manuals/+bug/1029560

Also, there is missing info within the Compute WADL, probably related to the min_count/max_count inconsistency noted above. https://bugs.launchpad.net/openstack-manuals/+bug/1006654

Unresolved issues