Enhanced-Platform-Awareness-OVF-Meta-Data-Import

= Enhanced Platform Awareness – OVF Meta-Data Import in Glance = = Summary = This proposal focuses on how meta-data contained in the OVF package can be imported automatically by Glance. At the VM deployment phase, Nova, via the Image Properties Filter, can leverage the meta-data imported by Glance to filter the available platforms to a subset of platforms that are most suitable for deploying the VM image on. One use case relates to automatic provisioning of VMs for Network Function Virtualization applications that may require enhanced platform awareness and more fine-grained provisioning of platform resources in order to meet performance criteria. The DMTF CIM models are referenced as examples of meta-data that may be imported.

= Background = There is a growing movement in the telecommunications industry to transform the network. This transformation includes the distinct, but mutually beneficial disciplines of Software Defined Networking (SDN) and Network Functions Virtualization (NFV). One of the challenges of virtualizing appliances in general, and virtualizing network functions in particular, is to deliver near native (i.e. non-virtualized) performance. Many virtual appliances have intense I/O requirements, many also could benefit from access to high performance accelerators for workloads such as cryptography, and others could operate more efficiently with greater access to CPU instruction set extensions.

Network Functions Virtualization
Network Functions Virtualization (NFV) is an Industry Specification Group (ISG) in the European Telecommunications Standards Institute (ETSI). Leading network operators, TEMs, IT vendors and technology providers have joined the ISG. One of their goals is to “Develop requirements and architecture specifications for the hardware and software infrastructure required to support these virtualized functions, as well as guidelines for developing network functions.”[Ref 1] One of the challenges of virtualizing functions in general, and virtualizing network functions in particular is to deliver near native (i.e. non-virtualized) performance. To help address this challenge, developers of virtualized network functions leverage virtualization technologies traditionally associated with IT deployments such as Intel® Virtualization Technology (Intel® VT) for IA-32, Intel® 64 and Intel® Architecture (Intel® VT-x), Intel® Virtualization Technology for Directed I/O (Intel® VT-d) and Intel® Virtualization Technology for Connectivity (Intel® VT-c). They also develop their application with specific drivers for platform features such as Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI) and the Intel® QuickAssist Integrated Accelerator.

Open Virtualization Format
The Distributed Management Task Force (DMTF) Open Virtualization Format (OVF) specification [Ref 2] and the related OVF Envelope XML Schema Document (XSD) [Ref 3] were developed to describe the packaging and distribution of software to be run in a virtual machine. This is one of the open standards that the NFV Industry Specification Group (ISG) in the European Telecommunications Standards Institute (ETSI) are considering as part of the interface between the higher level orchestration layers and the virtualized infrastructure manager.

DMTF Common Information Model (CIM)
OVF relies on a number of DMTF Common Information Model (CIM) [Ref 4] standards. CIM has defined ~1378 classes/subclasses, with another ~61 Problem Resolution Standard (PRS) classes that can be treated as CIM extensions. With these classes it is possible to model many of the characteristics of the platform that the VM/application has been developed to take advantage of.

Enhanced Platform Awareness
It can be generalized that there is a growing demand for the cloud OS to have a greater awareness of the capabilities of the platforms it controls. The Enhanced Platform Awareness (EPA) related updates proposed to OpenStack aim to facilitate better informed decision making related to VM placement and help drive tangible improvements for cloud tenants. = Sample Use Case = A sample use case for the feature described herein relates to the deployment in an OpenStack managed cloud of a virtualized deep packet inspection application. The application developers coded routines to leverage Intel® instruction set extensions such as AVX when they are available on the platform. When packaging the VM, they also configured the OVF meta-data to include in the CIM_ProcessorAllocationSettingData class the InstructionSetExtensionName to have a value of AVX. Leveraging extensions noted in this blueprint, the image would be automatically tagged to request AVX support on the platform. During deployment, Nova would use the image properties from within the image properties filter to help identify the most appropriate platform. = Benefits of OVF Meta-Data Import via Glance Proposal = This EPA proposal focuses on how meta-data contained in the OVF files can be imported automatically by Glance. At the VM deployment phase, Nova, via the Image Properties Filter, can leverage the meta-data imported by Glance to filter the available platforms to a subset of platforms that are most suitable for deploying the VM image on. The use of standardized meta-data descriptions/attributes should help with ensuring related support exists in other parts of OpenStack. The following is a list of some of the benefits of adding OVF Meta-Data Import support to Glance:
 * Leverage an open, industry standard on the description of permitted key-value pairs applicable to VM virtual hardware requirements.
 * Standardize the format of platform properties discovered by Nova agents.
 * Addition of administrator policy controls can restrict properties that can be tagged to an image thereby enabling an admin to control how much granularity they offer tenants in terms of platform requests.
 * Enable more efficient, higher performing VM deployments based on an enhanced ability to match optimal VM requirements to platform capabilities.
 * Less error prone workflow between the engineers creating VMs and tagging them with known properties, and the engineers/tenants/administrators deploying the VM in the cloud environment.

= Existing solutions in OpenStack = It is possible to tag images with meta-data via the --property argument on the glance image-create and glance image-update commands. This --property argument takes a key-value pair. The meta-data associated with the image can be used by the Image Properties Filter during the host scheduling process. Potential issues with the existing approach:
 * If the tenant is to perform the image tagging, then permission must be granted to the tenant to update the image property with the meta-data.
 * Currently no protection/policy control on what fields they may choose to specify once they are granted permission to update the image.
 * Some image meta-data key-value pairs have been described in documentation, there is no standard recommended for the myriad of other definitions of key-value pairs that are possible. This makes automatic platform property discovery and correlation with the image meta-data more problematic if a user chooses to add additional meta-data to an image.
 * The tenant or administrator performing the image tagging are likely not to be the same person or company that developed the VM image and hence may incorrectly tag an image with sub-optimal or inaccurate properties.

= Proposed Updates to OpenStack = The following are the proposed changes to Glance.

Part 1: API - Setting to enable/disable import of OVF meta-data

 * Add an optional meta-data header to instruct Glance on what to do with OVF meta-data during a POST image command: (POST http://glance.example.com/v1/images) 
 * New HTTP header x-image-meta-ovf-meta-import-enable .
 * Valid values are true and false. true  means Glance will import all supported OVF meta-data limited only by settings in the policy.
 * If the header is not specified, the default behavior is for OVF meta-data import to be disabled.

Part 2: Global control of permitted OVF meta-data import settings

 * The policy configuration file impacts the commands to add and modify images
 * add_image - Create an image entity




 * modify_image - Update an image entity




 * A JSON list is used to apply policy on the commands above. Policy can define what user role has permission to run the commands.




 * The new addition of the <FONT FACE= "Courier New">ovf-meta-data-import:XXX <FONT FACE= "Arial Unicode MS"> item in list indicates that the authorized user may import the meta-data with the key (name) XXX.
 * If <FONT FACE= "Courier New"><x-image-meta-ovf-meta-import-enable<FONT FACE= "Arial Unicode MS"> is not specified or set to <FONT FACE= "Courier New">false<FONT FACE= "Arial Unicode MS">, then Glance shall not import all of the OVF meta-data properties that it supports parsing.

Part 3: Retrieving Image Meta-Data

 * It shall be possible to retrieve the image meta-data, e.g. via a <FONT FACE= "Courier New">HEAD<FONT FACE= "Arial Unicode MS"> request such as

<FONT FACE= "Courier New">

<FONT FACE= "Arial Unicode MS">


 * Imported fields shall be available with the HTTP headers: <FONT FACE= "Courier New">x-image-meta-ovf-XXX<FONT FACE= "Arial Unicode MS"> where XXX is the name of the imported meta-data field.

Part 4: Retrieving supported Glance OVF and CIM version.

 * It shall be possible to retrieve the version of OVF and CIM models that Glance supports.
 * Possibly via HTTP headers: <FONT FACE= "Courier New">x-image-meta-ovf-version<FONT FACE= "Arial Unicode MS"> and <FONT FACE= "Courier New">x-image-meta-ovf-cim-schema-version<FONT FACE= "Arial Unicode MS">.

Part 5: OVF Certificate Verification
Among other things, the OVF package contains a manifest file with a list of all the files in the package, a hash of each file and the hash algorithm used. To sign an OVF package, the manifest file is signed with a base64 encoded X.509 certificate. The digest of the manifest and the certificate are stored in a <FONT FACE= "Courier New">.cert<FONT FACE= "Arial Unicode MS"> file. By validating the certificate and verifying the signature the user can be assured the package has not been tampered with. <BR>
 * TBD – Possibly a separate blueprint needed with details on how to implement this security step.

OVF Meta-Data Fields to Import
The following table describes the suggested OVF meta-data properties that should be among the first to be imported via Glance. This is not intended to be an exhaustive list in terms of keys or values and it is expected that the OpenStack community will extend support as needed. The DMTF CIM documentation should be consulted to get a full list. Open: To help with namespace, it may be better to have the key also contain the related CIM class name and not just the property. E.g. <FONT FACE= "Courier New">ProcessorArchitecture<FONT FACE= "Arial Unicode MS"> would become <FONT FACE= "Courier New">CIM_ProcessorAllocationSettingData.ProcessorArchitecture<FONT FACE= "Arial Unicode MS">.

= Not covered by this blueprint =
 * OVF can be used to package multiple VMs. This initial proposal is focused on adding support for single VM based OVF packages. The solution should be extensible to multiple VM based packages, but would require additional work to factor in the multi-VM inter-dependency models (e.g. networking) that can be described in OVF into OpenStack.
 * This blueprint is focusing on automatic configuration use cases. It does not cover potential API extensions to allow similar configuration requests to be made in a CLI driven fashion. Such extensions are considered desirable due to the additional flexibility and custom configurability of image properties and would complement the automated solution presented here.
 * Acting upon some of the meta-data properties that can be modeled in OVF would require more advanced scheduling/filtering in Nova. E.g. Core allocation can be modelled In the CIM_ProcessorCore class.
 * This blueprint is not intended to restrict the import of meta-data that may not comply with a standard. However, if non-standard meta-data is imported then the user should also add support for leveraging that data elsewhere in OpenStack.
 * Per-tenant restrictions on image properties that they may specify. Current proposal is based on global restrictions.
 * Nova agent updates to detect additional platform properties.
 * Horizon updates.

= Additional Note = Although Intel developed technologies and products have been mentioned in this blueprint as examples of usage, it is intended that the design proposal is applicable to solutions from other vendors. = References = = Related Blueprints =
 * 1) Leading operators create ETSI standards group for network functions virtualization. http://www.etsi.org/news-events/news/644-2013-01-isg-nfv-created
 * 2) Open Virtualization Format (OVF) specification version 2.0.1, document number DSP0243, dated 2013-08-22. http://dmtf.org/sites/default/files/standards/documents/DSP0243_2.0.1.pdf
 * 3) OVF Envelope XML Schema Document (XSD). http://schemas.dmtf.org/ovf/envelope/2/dsp8023_2.0.1.xsd
 * 4) DMTF Common Information Model (CIM). http://dmtf.org/standards/cim
 * 5) CIM V2.38.0 schema. http://dmtf.org/standards/cim/cim_schema_v2380
 * https://blueprints.launchpad.net/glance/+spec/export-import-image-metadata-ovf

= Collaborators = Companies that collaborated on this blueprint: Intel, Ericsson