ironic-specs/priorities/mitaka-priorities.rst
Ruby Loo 20c237ea05 Priorities that were done in Mitaka
Added the priorities that were completed in Mitaka.

Change-Id: I74f08bed44b6b881ea555dda27e5f1e73ab30c1c
2016-05-10 15:33:12 -04:00

5.9 KiB

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

May 2016. These were completed in the Mitaka cycle:

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.