Added first spec
This commit is contained in:
James Page
parent
8a7cefff30
commit
c761de149f
@ -219,7 +219,7 @@ latex_documents = [
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
('index', 'Charm-specs', u'Charm Design Specs',
|
||||
u'OpenStack Charm Team', 'nova-specs', 'Design specifications for the Charm project.',
|
||||
u'OpenStack Charm Team', 'charm-specs', 'Design specifications for the Charm project.',
|
||||
'Miscellaneous'),
|
||||
]
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
==========================
|
||||
Nova Newton Specifications
|
||||
==========================
|
||||
===========================
|
||||
Charm Newton Specifications
|
||||
===========================
|
||||
|
||||
Template:
|
||||
|
||||
|
||||
@ -1 +1 @@
|
||||
../../../../specs/newton-template.rst
|
||||
../../../../specs/template.rst
|
||||
@ -1,6 +1,6 @@
|
||||
::
|
||||
|
||||
Copyright <YEARS> <HOLDER> <--UPDATE THESE
|
||||
Copyright 2016, Canonical UK
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
@ -13,35 +13,59 @@
|
||||
http://sphinx-doc.org/rest.html To test out your formatting, see
|
||||
http://www.tele3.cz/jbar/rest/rest.html
|
||||
|
||||
===============================
|
||||
The Title of Your Specification
|
||||
===============================
|
||||
=========================
|
||||
SR-IOV networking support
|
||||
=========================
|
||||
|
||||
Include the URL of your StoryBoard story:
|
||||
|
||||
https://storyboard.openstack.org/...
|
||||
|
||||
Introduction paragraph -- why are we doing anything?
|
||||
SR-IOV is a mechanism for passing hardware virtualized network functions (VF)
|
||||
or full physical function (PF) directly to KVM instances; the OpenStack
|
||||
charms should be updated to support this capability.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
A detailed description of the problem.
|
||||
Using Open vSwitch and the chain of bridges, veth pairs and tap devices incurs
|
||||
an overhead on network throughput and latency that is not acceptable in some
|
||||
use cases for OpenStack.
|
||||
|
||||
SR-IOV allows part of (a VF) or a full (a PF) SR-IOV enabled network card to be
|
||||
connected directly to a KVM instance via the virtualization layer provided
|
||||
by libvirt.
|
||||
|
||||
Support for both of these types of passthrough was implemented in full in the
|
||||
Mitaka release.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Here is where you cover the change you propose to make in detail. How do you
|
||||
propose to solve this problem?
|
||||
Supporting SR-IOV will require changes in three charms; specifcally:
|
||||
|
||||
If this is one part of a larger effort make it clear where this piece ends. In
|
||||
other words, what's the scope of this effort?
|
||||
- neutron-api: Enablement of the ML2 mechanism driver for SR-IOV
|
||||
- nova-cloud-controller: Enablement of appropriate scheduler filters for
|
||||
management of PCI passthrough devices
|
||||
- nova-compute: White listing of PCI devices for use by compute instances.
|
||||
|
||||
SR-IOV will be enabled using a configuration option on the neutron-api charm
|
||||
'enable-sriov'; The nova-cloud-controller charm will be notified of the
|
||||
state of this option via the relation between the nova-cloud-controller charm
|
||||
and the neutron-api charm.
|
||||
|
||||
In the first implementation, a pci-device-whitelist configuration option
|
||||
will be provided by the nova-compute charm to allow allocation of specific
|
||||
PCI devices to compute instances. This is a direct pass through to a Nova
|
||||
configuration option. Later revisions of this feature may use as-yet
|
||||
unimplemented features in Juju to manage PCI device allocation at the unit
|
||||
level.
|
||||
|
||||
Initial SR-IOV support will be agent-less (i.e. not using the
|
||||
neutron-sriov-agent).
|
||||
|
||||
Flat and VLAN networking modes will be supported.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
This is an optional section, where it does apply we'd just like a demonstration
|
||||
that some thought has been put into why the proposed approach is the best one.
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
@ -49,77 +73,77 @@ Implementation
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Who is leading the writing of the code? Or is this a blueprint where you're
|
||||
throwing it out there to see who picks it up?
|
||||
|
||||
If more than one person is working on the implementation, please designate the
|
||||
primary author and contact.
|
||||
|
||||
Primary assignee:
|
||||
<launchpad-id or None>
|
||||
|
||||
Can optionally list additional ids if they intend on doing substantial
|
||||
implementation work on this blueprint.
|
||||
james-page
|
||||
|
||||
Gerrit Topic
|
||||
------------
|
||||
|
||||
Use Gerrit topic "<topic_name>" for all patches related to this spec.
|
||||
Use Gerrit topic "sriov-support" for all patches related to this spec.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git-review -t <topic_name>
|
||||
git-review -t sriov-support
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Work items or tasks -- break the feature up into the things that need to be
|
||||
done to implement it. Those parts might end up being done by different people,
|
||||
but we're mostly trying to understand the timeline for implementation.
|
||||
Initial charm support for SR-IOV
|
||||
################################
|
||||
|
||||
- neutron-api: Add enable-sriov config option, enable mechanism driver, pass
|
||||
details to nova-cloud-controller charm.
|
||||
|
||||
- nova-cloud-controller: Add PciPassthroughFilter to scheduler filters when
|
||||
enable-sriov is enabled by the neutron-api charm.
|
||||
|
||||
- nova-compute: Add pci-device-whitelist configuration option, pass directly
|
||||
into nova.conf configuration file template(s).
|
||||
|
||||
Mojo specification for SR-IOV base enablement
|
||||
#############################################
|
||||
|
||||
- Functional testing specification for deployment of an SR-IOV enabled
|
||||
OpenStack Cloud.
|
||||
|
||||
SR-IOV VF/PF scheduling testing
|
||||
###############################
|
||||
|
||||
- Focussed testing on ensuring that scheduling behaviour is tuned appropriately
|
||||
when SR-IOV is in use within a cloud.
|
||||
|
||||
Juju device binding support
|
||||
###########################
|
||||
|
||||
- Stretch objective for Newton cycle; superceeds pci-device-whitelist option
|
||||
on nova-compute charm
|
||||
|
||||
Repositories
|
||||
------------
|
||||
|
||||
Will any new git repositories need to be created?
|
||||
|
||||
Servers
|
||||
-------
|
||||
|
||||
Will any new servers need to be created? What existing servers will
|
||||
be affected?
|
||||
|
||||
DNS Entries
|
||||
-----------
|
||||
|
||||
Will any other DNS entries need to be created or updated?
|
||||
No new git repositories required.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
Will this require a documentation change? If so, which documents?
|
||||
Will it impact developer workflow? Will additional communication need
|
||||
to be made?
|
||||
Updates to the README's in the impacted charms will be made as part of this change.
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
Does this introduce any additional security risks, or are there
|
||||
security-related considerations which should be discussed?
|
||||
No additional security concerns.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
What tests will be available or need to be constructed in order to
|
||||
validate this? Unit/functional tests, development
|
||||
environments/servers, etc.
|
||||
Code changes will be covered by unit tests; functional testing will be done using
|
||||
a Mojo specification.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
- Include specific references to specs and/or stories in infra, or in
|
||||
other projects, that this one either depends on or is related to.
|
||||
- OpenStack Mitaka.
|
||||
|
||||
- Does this feature require any new library or program dependencies
|
||||
not already in use?
|
||||
- SR-IOV enabled hardware in the Ubuntu OpenStack QA lab for functional testing
|
||||
|
||||
- Does it require a new puppet module?
|
||||
- Juju device management support
|
||||
|
||||
@ -17,10 +17,6 @@
|
||||
The Title of Your Specification
|
||||
===============================
|
||||
|
||||
Include the URL of your StoryBoard story:
|
||||
|
||||
https://storyboard.openstack.org/...
|
||||
|
||||
Introduction paragraph -- why are we doing anything?
|
||||
|
||||
Problem Description
|
||||
@ -82,17 +78,6 @@ Repositories
|
||||
|
||||
Will any new git repositories need to be created?
|
||||
|
||||
Servers
|
||||
-------
|
||||
|
||||
Will any new servers need to be created? What existing servers will
|
||||
be affected?
|
||||
|
||||
DNS Entries
|
||||
-----------
|
||||
|
||||
Will any other DNS entries need to be created or updated?
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
@ -116,10 +101,8 @@ environments/servers, etc.
|
||||
Dependencies
|
||||
============
|
||||
|
||||
- Include specific references to specs and/or stories in infra, or in
|
||||
- Include specific references to specs and/or stories, or in
|
||||
other projects, that this one either depends on or is related to.
|
||||
|
||||
- Does this feature require any new library or program dependencies
|
||||
not already in use?
|
||||
|
||||
- Does it require a new puppet module?
|
||||
|
||||
2
tox.ini
2
tox.ini
@ -1,6 +1,6 @@
|
||||
[tox]
|
||||
# Hold back to 1.4, since that's what's in Fedora 20 repos
|
||||
# and we don't need anything newer for nova-specs tests
|
||||
# and we don't need anything newer for charm-specs tests
|
||||
minversion = 1.4
|
||||
envlist = docs,py27,pep8
|
||||
skipsdist = True
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user