Add Mitaka project priorities
This adds a document laying out our priorities for the Mitaka cycle, inspired by what Nova does. It also refactors the index page to add the priorities tree. Change-Id: I95bf7e119d8c56c58abd4f8ebab80cc8a98373ff
This commit is contained in:
Jim Rollenhagen
parent
fbbb9434aa
commit
59d6192221
|
|
@ -1,8 +1,23 @@
|
|||
.. ironic-specs documentation master file
|
||||
|
||||
=============================
|
||||
Ironic Project Specifications
|
||||
=============================
|
||||
==============================
|
||||
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:
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
priorities/*
|
||||
|
||||
Specifications
|
||||
==============
|
||||
|
||||
Specifications for the ironic project are available here. Specifications
|
||||
begin life in the "approved" tree. They stay there (possibly beyond the
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
../../priorities
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
.. _mitaka-priorities:
|
||||
|
||||
=========================
|
||||
Mitaka Project Priorities
|
||||
=========================
|
||||
|
||||
This is a list of development priorities the Ironic team is prioritizing for
|
||||
Mitaka development, in no particular order.
|
||||
|
||||
You may notice this list seems long for a single cycle. Note that much of this
|
||||
work is in flight already and just needs to be completed during the Mitaka
|
||||
cycle; they are not starting from scratch.
|
||||
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| Priority | Primary Contacts |
|
||||
+=========================================+==================================+
|
||||
| `ironic-lib refactor`_ | rloo |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Manual cleaning`_ | rloo |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `RAID`_ | rameshg87, lucasagomes |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Network isolation`_ | jroll |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Live upgrades`_ | lucasagomes, lintan |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Boot interface refactor`_ | jroll |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Parallel tasks with futurist`_ | dtantsur |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Node filter API and claims endpoint`_ | jroll, devananda |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Multiple compute hosts`_ | jroll, devananda |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Improving testing`_ | jlvillal, krtaylor, lekha |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
| `Improving docs`_ | jroll, liliars |
|
||||
+-----------------------------------------+----------------------------------+
|
||||
|
||||
ironic-lib refactor
|
||||
-------------------
|
||||
|
||||
Work to refactor much of Ironic's disk partitioning code into a library
|
||||
(ironic-lib) began in Liberty, getting the library set up and released. The
|
||||
team would like to finish that work in Mitaka by removing the code in Ironic
|
||||
and replacing it with library calls. This enables advanced partitioning in
|
||||
ironic-python-agent via this library, which will be needed for supporting
|
||||
partitioned disk images.
|
||||
|
||||
Manual cleaning
|
||||
---------------
|
||||
|
||||
Work began on a feature called "zapping" in Liberty. This came late in the
|
||||
cycle, and the implementation identified some issues with the architecture and
|
||||
name. This is being re-spun as "manual cleaning" in Mitaka. It's needed to
|
||||
complete the RAID work and for operators to be able to trigger other cleaning
|
||||
tasks manually.
|
||||
|
||||
RAID
|
||||
----
|
||||
|
||||
Much of the groundwork was laid down for RAID support in Liberty. To complete
|
||||
this work in Mitaka, we need to integrate it with (manual) cleaning and write
|
||||
ample documentation for operators.
|
||||
|
||||
Network isolation
|
||||
-----------------
|
||||
|
||||
This feature was designed in Liberty, and much of the code was written. The
|
||||
code was not ready in time to land in Liberty. We need to complete this work in
|
||||
Mitaka, along with the Nova side of the work. This is one of our biggest
|
||||
feature asks from users.
|
||||
|
||||
Live upgrades
|
||||
-------------
|
||||
|
||||
This is necessary, especially with frequent releases, to allow our operators to
|
||||
upgrade without downtime. There isn't much code work left to do here; mostly
|
||||
docs, increasing awareness, and building a culture of coding and reviewing for
|
||||
live upgrades.
|
||||
|
||||
Boot interface refactor
|
||||
-----------------------
|
||||
|
||||
This work was completed for most drivers in Liberty. Two drivers (iLO and iRMC)
|
||||
remain to be completed. The code is complete for this and just needs review.
|
||||
|
||||
Parallel tasks with futurist
|
||||
----------------------------
|
||||
|
||||
This will help scale our conductor service, as we have a handful of periodic
|
||||
tasks that currently run serially. Additionally, drivers may register periodic
|
||||
tasks that compound this problem.
|
||||
|
||||
Node filter API and claims endpoint
|
||||
-----------------------------------
|
||||
|
||||
This lays the groundwork for the work being done in Nova to allow the Ironic
|
||||
driver to utilize multiple compute hosts. The filter API also helps users query
|
||||
nodes much more intelligently, and the claims endpoint will help clients other
|
||||
than Nova schedule to nodes more easily.
|
||||
|
||||
Multiple compute hosts
|
||||
----------------------
|
||||
|
||||
This is an effort to allow the Ironic virt driver in Nova scale across many
|
||||
compute hosts. Currently only one compute host is supported. This shrinks the
|
||||
failure domain of the nova-compute service in an Ironic deployment, and also
|
||||
helps schedule Ironic resources more efficiently. Note that this work is in the
|
||||
Nova codebase, but is an Ironic effort.
|
||||
|
||||
Improving testing
|
||||
-----------------
|
||||
|
||||
There are a number of gaps in our testing that we need to close. This includes
|
||||
full tempest, microversion testing, grenade jobs, functional testing, third
|
||||
party CI, and more. These will help us to keep our releases more stable.
|
||||
|
||||
Improving docs
|
||||
--------------
|
||||
|
||||
We currently don't have any presence in the official OpenStack documentation,
|
||||
and somewhat related, there is currently no way to update documentation for
|
||||
stable branches. We also need to create a developer's guide of sorts, to help
|
||||
developers follow our processes more easily and submit better code, as well as
|
||||
help reviewers review code in a consistent manner.
|
||||
Loading…
Reference in New Issue