Browse Source

Spec folder for Zed

As we run into a nasty setuptools issue/feature which broke even
tox -edocs, add py_modules=[] to setup.py's setup call, see [1].

[1]: https://review.opendev.org/q/topic:setuptools-issue-3197

Change-Id: I24adbcb9076f02c2eeefef98c21a4ccf247b0c5b
changes/36/837736/2
elajkat 4 months ago
parent
commit
97ee8a2810
  1. 1
      doc/source/index.rst
  2. 3
      setup.py
  3. 9
      specs/zed/index.rst
  4. 83
      specs/zed/placeholder.rst

1
doc/source/index.rst

@ -10,6 +10,7 @@ Specifications and RFEs
.. toctree::
:maxdepth: 2
specs/zed/index
specs/yoga/index
specs/xena/index
specs/wallaby/index

3
setup.py

@ -19,4 +19,5 @@ import setuptools
setuptools.setup(
setup_requires=['pbr>=2.0.0'],
pbr=True)
pbr=True,
py_modules=[])

9
specs/zed/index.rst

@ -0,0 +1,9 @@
===
Zed
===
.. toctree::
:glob:
:maxdepth: 1
*

83
specs/zed/placeholder.rst

@ -0,0 +1,83 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
====================================
Example Spec - The title of your RFE
====================================
Include the URL of your launchpad RFE:
https://bugs.launchpad.net/neutron/+bug/example-id
Introduction paragraph -- why are we doing this feature? A single paragraph of
prose that **deployers, and developers, and operators** can understand.
Do you even need to file a spec? Most features can be done by filing an RFE bug
and moving on with life. In most cases, filing an RFE and documenting your
design in the devref folder of neutron docs is sufficient. If the feature
seems very large or contentious, then the drivers team may request a spec, or
you can always file one if desired.
Problem Description
===================
A detailed description of the problem:
* For a new feature this should be a list of use cases. Ensure that you are clear
about the actors in each use case: End User vs Deployer. Ensure that you identify
which area of the core is being affected; for something completely new, it
should be clear why you are considering it being part of the core.
* For a major reworking of something existing it would describe the
problems in that feature that are being addressed.
Note that the RFE filed for this feature will have a description already. This
section is not meant to simply duplicate that; you can simply refer to that
description if it is sufficient, and use this space to capture changes to
the description based on bug comments or feedback on the spec.
Proposed Change
===============
How do you propose to solve this problem?
This section is optional, and provides an area to discuss your high-level
design at the same time as use cases, if desired. Note that by high-level,
we mean the "view from orbit" rough cut at how things will happen.
This section should 'scope' the effort from a feature standpoint: how is the
'neutron end-to-end system' going to look like after this change? What Neutron
areas do you intend to touch and how do you intend to work on them? The list
below is not meant to be a template to fill in, but rather a jumpstart on the
sorts of areas to consider in your proposed change description.
* Am I going to see new CLI commands?
* Is OpenStack CLI covered in addition to neutronclient?
* How do you intend to support or affect aspects like:
* Address Management, e.g. IPv6, DHCP
* Routing, e.g. DVR/HA
* Plugins, ML2 Drivers, e.g. OVS, LinuxBridge
* Agents, e.g. metadata
* High level services, e.g. \*-aas.
* Scheduling, quota, and policy management, e.g. admin vs user rights
* API and extensions
* Clients
* Impact on services or out-of-tree plugins/drivers
* What do you intend to not support in the initial release?
You do not need to detail API or data model changes. Details at that level of
granularity belong in the neutron devref docs.
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable.
Loading…
Cancel
Save