<commit_before>..
      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.

Scope of the Nova project
==========================

Nova is focusing on doing an awesome job of its core mission.
This document aims to clarify that core mission.

This is a living document to help record where we agree about what Nova
should and should not be doing, and why.
Please treat this as a discussion of interesting, and hopefully useful,
examples. It is not intended to be an exhaustive policy statement.

.. _nova-mission:

Mission
-------

Our mission statement starts with:

    To implement services and associated libraries to provide massively
    scalable, on demand, self service access to compute resources.

Our official mission statement also includes the following examples of
compute resources: bare metal, virtual machines, and containers.
For the full official mission statement see:
https://governance.openstack.org/tc/reference/projects/nova.html#mission

This document aims to help clarify what the mission statement means.

Compute Resources
------------------

Nova is all about access to compute resources. This section looks at the
types of compute resource Nova works with.

Virtual Servers
****************

Nova was originally focused purely on providing access to virtual servers
running on a variety of different hypervisors.
The majority of users use Nova only to provide access to virtual servers
from a single hypervisor, however, its possible to have a Nova deployment
include multiple different types of hypervisors, while at the same time
offering containers and bare metal servers.

Containers
***********

The Nova API is not a good fit for a lot of container use cases.
The Magnum project intends to deliver a good container experience built
on top of Nova.

Nova allows you to use containers in a similar way to how you would use
on demand virtual machines. We want to maintain this distinction, so we
maintain the integrity and usefulness of the existing Nova API.

For example, Nova is not designed to spin up new containers for every apache
request, nor do we plan to control what goes on inside containers.
They get the same metadata provided to them as virtual machines, to do
with as they see fit.

Bare Metal Servers
*******************

Ironic project has been pioneering the idea of treating physical machines in
a similar way to on demand virtual machines.

Nova's driver is able to allow a multi-tenant cloud style use of Ironic
controlled resources.

While currently there are operations that are a fundamental part of our
virtual machine abstraction that are not currently available in ironic,
such as attaching iSCSI volumes, it does not fundamentally change the
semantics of our API, and as such is a suitable Nova driver. Moreover,
it is expected that gap with shrink over time.

Driver Parity
**************

Our goal for the Nova API to provide a consistent abstraction to access
on demand compute resources. We are not aiming to expose all features of all
hypervisors. Where the details of the underlying hypervisor leak through
our APIs, we have failed in this goal, and we must work towards better
abstractions that are more interoperable.
This is one reason why we put so much emphasis on the use of Tempest in third
party CI systems.

The key tenant of driver parity is that if a feature is supported in a driver,
it must feel the same to users, as if they where using any of the other
drivers that also support that feature. The exception is that, if possible for
widely different performance characteristics, but the effect of that API call
must be identical.

Following on from that, should a feature only be added to one of the drivers,
we must make every effort to ensure another driver could be implemented to
match that behavior.

Its important that drivers support enough features, so the API actually
provides a consistent abstraction. For example, being unable to create a
server or delete a server, would severely undermine that goal.
In fact, Nova only ever manages resources it creates.

Upgrades
---------

Nova is widely used in production. As such we need to respect the needs of our
existing users. At the same time we need evolve the current code base,
including both adding and removing features.<commit_msg>docs: cleanup driver parity scope section<commit_after>..
      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.

Scope of the Nova project
==========================

Nova is focusing on doing an awesome job of its core mission.
This document aims to clarify that core mission.

This is a living document to help record where we agree about what Nova
should and should not be doing, and why.
Please treat this as a discussion of interesting, and hopefully useful,
examples. It is not intended to be an exhaustive policy statement.

.. _nova-mission:

Mission
-------

Our mission statement starts with:

    To implement services and associated libraries to provide massively
    scalable, on demand, self service access to compute resources.

Our official mission statement also includes the following examples of
compute resources: bare metal, virtual machines, and containers.
For the full official mission statement see:
https://governance.openstack.org/tc/reference/projects/nova.html#mission

This document aims to help clarify what the mission statement means.

Compute Resources
------------------

Nova is all about access to compute resources. This section looks at the
types of compute resource Nova works with.

Virtual Servers
****************

Nova was originally focused purely on providing access to virtual servers
running on a variety of different hypervisors.
The majority of users use Nova only to provide access to virtual servers
from a single hypervisor, however, its possible to have a Nova deployment
include multiple different types of hypervisors, while at the same time
offering containers and bare metal servers.

Containers
***********

The Nova API is not a good fit for a lot of container use cases.
The Magnum project intends to deliver a good container experience built
on top of Nova.

Nova allows you to use containers in a similar way to how you would use
on demand virtual machines. We want to maintain this distinction, so we
maintain the integrity and usefulness of the existing Nova API.

For example, Nova is not designed to spin up new containers for every apache
request, nor do we plan to control what goes on inside containers.
They get the same metadata provided to them as virtual machines, to do
with as they see fit.

Bare Metal Servers
*******************

Ironic project has been pioneering the idea of treating physical machines in
a similar way to on demand virtual machines.

Nova's driver is able to allow a multi-tenant cloud style use of Ironic
controlled resources.

While currently there are operations that are a fundamental part of our
virtual machine abstraction that are not currently available in ironic,
such as attaching iSCSI volumes, it does not fundamentally change the
semantics of our API, and as such is a suitable Nova driver. Moreover,
it is expected that gap with shrink over time.

Driver Parity
**************

Our goal for the Nova API is to provide a consistent abstraction to access
on demand compute resources. We are not aiming to expose all features of all
hypervisors. Where the details of the underlying hypervisor leak through
our APIs, we have failed in this goal, and we must work towards better
abstractions that are more `interoperable`_.
This is one reason why we put so much emphasis on the use of Tempest in third
party CI systems.

The key tenet of driver parity is that if a feature is supported in a driver,
it must feel the same to users, as if they where using any of the other
drivers that also support that feature. The exception is that, if possible for
widely different performance characteristics, but the effect of that API call
must be identical.

Following on from that, should a feature only be added to one of the drivers,
we must make every effort to ensure another driver could be implemented to
match that behavior.

It is important that drivers support enough features, so the API actually
provides a consistent abstraction. For example, being unable to create a
server or delete a server would severely undermine that goal.
In fact, Nova only ever manages resources it creates.

.. _interoperable: https://www.openstack.org/brand/interop/

Upgrades
---------

Nova is widely used in production. As such we need to respect the needs of our
existing users. At the same time we need evolve the current code base,
including both adding and removing features.
{'fraction_non_alphanumeric': 0.04985034575291568, 'fraction_numerical': 0.0008256786046031583, 'mean_word_length': 4.0759559979046625, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 3, 'lorem ipsum': 0, 'www.': 3, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '513203', 'n_tokens_mistral': 2218, 'n_tokens_neox': 2145, 'n_words': 1496}