Add priorities for the Pike cycle

Taken from https://etherpad.openstack.org/p/ironic-pike-ptg-planning
and related RFEs.

Change-Id: I2882e6ca56be3d22fcb168624def898ccb227e9f
This commit is contained in:
Dmitry Tantsur 2017-03-01 17:48:12 +01:00
parent 3e7471c854
commit 278ebb2873
2 changed files with 244 additions and 2 deletions

View File

@ -7,13 +7,15 @@ OpenStack Ironic Project Plans
Priorities
==========
During each design summit, we agree what the whole community wants to focus
on for the upcoming release. This is the output of those discussions:
During each PTG (before Pike - each design summit), we agree what the whole
community wants to focus on for the upcoming release. This is the output of
those discussions:
.. toctree::
:glob:
:maxdepth: 1
priorities/pike-priorities
priorities/ocata-priorities
priorities/newton-priorities
priorities/mitaka-priorities

View File

@ -0,0 +1,240 @@
.. _pike-priorities:
=======================
Pike Project Priorities
=======================
This is a list of development priorities the Ironic team is prioritizing for
Pike development, in order of priority. The primary contact(s) listed
is/are responsible for tracking the status of that work and herding cats
to help get that work done. They are not the only contributor(s) to this work!
The number of primary contacts is limited to 2 maximum to simplify
communication. We expect at least one of them to have core privileges
to simplify getting changes in.
Essential Priorities
~~~~~~~~~~~~~~~~~~~~
+---------------------------------------+-------------------------------------+
| Priority | Primary Contacts |
+=======================================+=====================================+
| `Standalone CI tests`_ | vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Generic boot-from-volume`_ | TheJulia, dtantsur |
+---------------------------------------+-------------------------------------+
| `Rolling upgrades`_ | rloo, jlvillal |
+---------------------------------------+-------------------------------------+
| `Reference architecture guide`_ | jroll |
+---------------------------------------+-------------------------------------+
| Python 3.5 compatibility | JayF, hurricanerix |
+---------------------------------------+-------------------------------------+
| Deploying with Apache and WSGI in CI | vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Driver composition`_ | jroll, dtantsur |
+---------------------------------------+-------------------------------------+
| `Feature parity between two CLIs`_ | rloo, dtantsur |
+---------------------------------------+-------------------------------------+
| `OSC default API version change`_ | mariojv, dtantsur |
+---------------------------------------+-------------------------------------+
| `Rescue mode`_ | mariojv, JayF |
+---------------------------------------+-------------------------------------+
| Finish node tags | zhenguo, dtantsur |
+---------------------------------------+-------------------------------------+
High Priorities
~~~~~~~~~~~~~~~
+---------------------------------------+-------------------------------------+
| Priority | Primary Contacts |
+=======================================+=====================================+
| `Specific fault support`_ | JayF, mariojv |
+---------------------------------------+-------------------------------------+
| `Post-deploy VIF attach/detach`_ | sambetts, vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Physical network awareness`_ | sambetts, vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Routed networks support`_ | sambetts, vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Neutron event processing`_ | vdrok, vsaienk0 |
+---------------------------------------+-------------------------------------+
| `Documentation reorganization`_ | JayF, TheJulia |
+---------------------------------------+-------------------------------------+
| `IPA REST API versioning`_ | sambetts |
+---------------------------------------+-------------------------------------+
Optional Priorities
~~~~~~~~~~~~~~~~~~~
+---------------------------------------+-------------------------------------+
| Priority | Primary Contacts |
+=======================================+=====================================+
| `Split away the tempest plugin`_ | soliosg, jlvillal |
+---------------------------------------+-------------------------------------+
| `Deploy steps`_ | yolanda, rloo |
+---------------------------------------+-------------------------------------+
| Redfish driver | lucasagomes, jroll |
+---------------------------------------+-------------------------------------+
| `Supported power states API`_ | dtantsur |
+---------------------------------------+-------------------------------------+
| `Available clean steps API`_ | rloo |
+---------------------------------------+-------------------------------------+
| `E-Tags in API`_ | galyna, vdrok |
+---------------------------------------+-------------------------------------+
| `IPA authentication`_ | jroll, joanna |
+---------------------------------------+-------------------------------------+
Details
~~~~~~~
Standalone CI tests
-------------------
We are working on a set of tests that can be run without nova present. We
expect this work to improve CI time, coverage and help test certain features
(e.g. adoption) that are not quite compatible with nova.
Generic boot-from-volume
------------------------
This work allows generic hardware to boot from remote storage, allowing
diskless nodes to be managed by ironic. This also lays down the framework for
hardware-specific implementations to be built.
Rolling upgrades
----------------
Many OpenStack projects are beginning to support rolling upgrades - we should
too. Let's do our part to make downtimes a thing of the past. This involves
code changes, new multi-node grenade CI jobs, and reviewer/developer
documentation. The target now is Ocata -> Pike rolling upgrades.
Reference architecture guide
----------------------------
To help new deployers make the right choices, we need a document describing a
reference architecture for an ironic deployment, especially around
multi-tenant networking and co-existing with VMs.
Driver composition
------------------
We've done most of the coding. Let's concentrate on stabilizing the feature,
writing new hardware types, polishing documentation and helping vendors with
onboarding.
Feature parity between two CLIs
-------------------------------
Let us make sure that all features implemented in the old ``ironic`` CLI are
available in the new OSC-based ``openstack baremetal`` CLI.
OSC default API version change
------------------------------
Currently the default API version OSC sends to ironic is an old Kilo-era one.
We need to figure out the path towards making the latest version the default.
Rescue mode
-----------
This is necessary for users that lose regular access to their machine (e.g.
lost passwords). The spec was merged in Newton, the code is partially done,
let's put some effort into making progress here in Pike.
Specific fault support
----------------------
Currently we communicate certain node errors via setting maintenance mode.
This is not obvious, and is a constant source of complaints from operators.
This work allows us to better communicate such failures, by providing a new API
for working with them.
Post-deploy VIF attach/detach
-----------------------------
We already support attaching and detaching VIFs to nodes as part of the
deployment process. Now we need to support the same for active nodes.
Physical network awareness
--------------------------
We need to make sure instances are not scheduled on nodes that cannot
physically reach the networks they're connected to. This may require data
model changes around ports. This is required for `Routed networks support`_.
Routed networks support
-----------------------
Ironic should become aware of L2 segments available to connected networks as
well as which L2 networks are actually available to nodes to correctly pick
subnet (IP address) when doing provisioning/cleaning.
Neutron event processing
------------------------
Currently ironic has no way to determine when certain asynchronous events
actually finish in neutron, and with what result. Nova, on the contrary, uses
a special neutron driver, which filters out notifications and posts some of
them to a special nova API endpoint. We should do the same.
Documentation reorganization
----------------------------
For some time, our documentation has grown without strict definition of
structure, as well as difficulties getting documentation into the primary
OpenStack documentation. In the Pike cycle we plan on reaching a consensus of
direction for our documentation structure so we can better self-service as
OpenStack evolves to better support projects such as ironic.
IPA REST API versioning
-----------------------
IPA API is currently not versioned, which causes problems when ironic starts
relying on new features. Versioning similar to ironic API is expected to fix
it and simplify upgrades.
Split away the tempest plugin
-----------------------------
Currently we rely on certain hacks to make our CI use master version of the
tempest plugin on all branches. The QA team suggests moving our tempest plugin
to a separate branch instead, let's do it. We should also merge ironic and
ironic-inspector plugins for simpler maintenance and consumption.
Deploy steps
------------
This is an effort to split parts of our monolithic deployment process into
steps, similar to cleaning. That will give driver authors a bit more freedom in
customizing the deploy process, and simplify potential additions to it
(like RAID, for example).
Supported power states API
--------------------------
The `soft power/NMI spec
<http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/enhance-power-interface-for-soft-reboot-and-nmi.html>`_
proposes exposing available power states in the API. We didn't implement this
part in Ocata, let us finish it now.
Available clean steps API
-------------------------
We need to expose available clean steps in the API, so that users know which
actions they can run during manual cleaning. This is a part of the
`manual cleaning spec
<http://specs.openstack.org/openstack/ironic-specs/specs/5.0/manual-cleaning.html>`_
which was never implemented, despite the spec being marked as done.
E-Tags in API
-------------
We should add E-Tag support to our API to avoid race conditions during
concurrent updates.
IPA authentication
------------------
Neither IPA API, nor the lookup/heartbeat endpoints it uses are currently
authenticated. While this issue is hard to solve completely in generic case,
we can at least consider reducing potential attack surface.