<commit_before>..
      Copyright (c) 2014 Hewlett-Packard Development Company, L.P.
      All Rights Reserved.

      Licensed under the Apache License, Version 2.0 (the "License"); you may
      not use this file except in compliance with the License. You may obtain
      a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
      License for the specific language governing permissions and limitations
      under the License.

Metadata Definition Concepts
============================

The metadata definition service was added to Glance in the Juno release of
OpenStack.

It provides a common API for vendors, admins, services, and users to
meaningfully **define** available key / value pair metadata that
can be used on different types of resources (images, artifacts, volumes,
flavors, aggregates, etc). A definition includes a property's key,
its description, its constraints, and the resource types to which it can be
associated.

This catalog does not store the values for specific instance properties.

For example, a definition of a virtual CPU topology property for the number of
cores will include the base key to use (for example, cpu_cores), a description,
and value constraints like requiring it to be an integer. So, a user,
potentially through Horizon, would be able to search this catalog to list the
available properties they can add to a flavor or image. They will see the
virtual CPU topology property in the list and know that it must be an integer.

When the user adds the property its key and value will be stored in the
service that owns that resource (for example, Nova for flavors and in Glance
for images). The catalog also includes any additional prefix required when
the property is applied to different types of resources, such as "hw_" for
images and "hw:" for flavors.  So, on an image, the user would know to set the
property as "hw_cpu_cores=1".

Terminology
-----------

Background
~~~~~~~~~~
The term *metadata* can become very overloaded and confusing.  This
catalog is about the additional metadata that is passed as arbitrary
key / value pairs or tags across various artifacts and OpenStack services.

Below are a few examples of the various terms used for metadata across
OpenStack services today:

+-------------------------+---------------------------+----------------------+
|  Nova                   | Cinder                    | Glance               |
+=========================+===========================+======================+<commit_msg>escape underline introducing a spurrious link reference<commit_after>..
      Copyright (c) 2014 Hewlett-Packard Development Company, L.P.
      All Rights Reserved.

      Licensed under the Apache License, Version 2.0 (the "License"); you may
      not use this file except in compliance with the License. You may obtain
      a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
      License for the specific language governing permissions and limitations
      under the License.

Metadata Definition Concepts
============================

The metadata definition service was added to Glance in the Juno release of
OpenStack.

It provides a common API for vendors, admins, services, and users to
meaningfully **define** available key / value pair metadata that
can be used on different types of resources (images, artifacts, volumes,
flavors, aggregates, etc). A definition includes a property's key,
its description, its constraints, and the resource types to which it can be
associated.

This catalog does not store the values for specific instance properties.

For example, a definition of a virtual CPU topology property for the number of
cores will include the base key to use (for example, cpu_cores), a description,
and value constraints like requiring it to be an integer. So, a user,
potentially through Horizon, would be able to search this catalog to list the
available properties they can add to a flavor or image. They will see the
virtual CPU topology property in the list and know that it must be an integer.

When the user adds the property its key and value will be stored in the
service that owns that resource (for example, Nova for flavors and in Glance
for images). The catalog also includes any additional prefix required when
the property is applied to different types of resources, such as "hw\_" for
images and "hw:" for flavors.  So, on an image, the user would know to set the
property as "hw_cpu_cores=1".

Terminology
-----------

Background
~~~~~~~~~~
The term *metadata* can become very overloaded and confusing.  This
catalog is about the additional metadata that is passed as arbitrary
key / value pairs or tags across various artifacts and OpenStack services.

Below are a few examples of the various terms used for metadata across
OpenStack services today:

+-------------------------+---------------------------+----------------------+
|  Nova                   | Cinder                    | Glance               |
+=========================+===========================+======================+
{'fraction_non_alphanumeric': 0.10946798917944094, 'fraction_numerical': 0.0032461677186654643, 'mean_word_length': 3.2992248062015506, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2864487', 'n_tokens_mistral': 1263, 'n_tokens_neox': 1199, 'n_words': 760}