Open Stack

Hello ironic developers, tripleo folks, and interested third-parties!

The Icehouse graduation deadline is fast approaching and I think we all
need to take a good look at where Ironic is, compare that to the
requirements that have been laid out by the TC [1] for all Integrated
projects, and prioritize our work aggressively.


We have four areas inside of Ironic that need significant movement in order
to graduate this cycle:

* Critical & High priority bugs
   There are enough of these that I'm not comfortable releasing with the
current state of things. I think we can address all of these bugs in time
if we focus on getting to a minimum-viable-product, rather than on
engineering a perfect solution. (Yes, I'm talking about myself too...) We
have patches in flight for many of them, but the average turn-around time
for our review queue is, in my opinion, higher than it should be [3] given
the size of our team. If we don't collectively speed up the review queue,
it's going to be very difficult to land everything we need to.

* Missing functionality
  We need to match the feature set of Nova baremetal. We're pretty good on
that front, but I'm calling out two blueprints and I'll explain why.

  https://blueprints.launchpad.net/ironic/+spec/serial-console-access
  I believe some folks are using this, even though the TripleO team is not,
and I personally never used the feature in Nova baremetal.
  IBM contributed code to implement this in Ironic, but the patch #64100
has been abandoned for some time. We need to revive this and continue the
work.
  https://blueprints.launchpad.net/ironic/+spec/preserve-ephemeral
  The TripleO team added this feature to Nova baremetal during the current
cycle;  even though it wasn't on our plans at the start of Icehouse, we
need to do it to keep feature parity.

* Testing & QA
  Ironic has API tests in tempest, and these run in Ironic's gate. However,
there are no functional tests today (iow, nothing testing that a PXE deploy
actually works). These are a graduation requirement. Aleksandr has been
working on this, but it's a long way from done. Anyone want to jump in?

* Documentation
  We have CLI and API docs, but we have no installation or deployer docs.
These are also a graduation requirement. No one has stepped up to own this
effort yet.


Additionally, the TC has laid out some (draft) graduation requirements [2]
for projects that duplicate functionality in a pre-existing project -- that
means us, since we're supplanting the old Nova "baremetal" driver. For
reference, here's the pertinent snippet from the draft:

"[T]he new project must reach a level of functionality and maturity such
> that we are ready to deprecate the old code ... including details for how
> users will be able to migrate from the old to the new."



We have two blueprints up that pertain specifically to this requirement:

https://blueprints.launchpad.net/nova/+spec/deprecate-baremetal-driver

The nova.virt.ironic driver is especially important as it represents Nova's
ability to perform the same functionality that is available today with the
baremetal driver. The Project meeting yesterday [4] made it clear that
getting the nova.virt.ironic driver landed is a pre-condition of Ironic's
graduation. This driver is well underway, but still has much work to be
done. We've started to see a few reviews from the Nova team, and have begun
splitting up the patch into smaller, more reviewable chunks.

The blueprint is set "Low" priority. I know the Nova core team is swamped
with review work, but we'll need to start getting regular feedback on this.
Russel suggested that this is suitable for a FFE so we could continue
working on it after I3, which is great - we'll need the extra time. Even
so, getting a little early feedback from nova-core would be very helpful in
case there is major work that they think we need to do.

https://blueprints.launchpad.net/ironic/+spec/migration-from-nova

We will need to provide a data migration tool for existing Nova baremetal
deployments, along with usage documentation. Roman is working on this, but
there still isn't any code up, and I'm getting a bit nervous....


That's it for the graduation-critical tasks, but that's not all the work
currently in our review queue or targeted to I3 ...

We also have third-party drivers coming in. Both SeaMicro and HP have
blueprints up for a vendor driver with power and deploy interfaces.
SeaMicro has code already up; HP has promised code very soon. There's also
a blueprint to enable PXE booting of windows images. None of these are
required for graduation, and even though I want to encourage vendors -- and
I think the functionality these blueprints describe is very valuable to the
project -- I question whether we'll have the time and bandwidth to review
them and ensure they're documented. I am not going to set a "code proposal
deadline" as some other projects have done, in part because I expect a lot
of development to happen at the TripleO sprint (March 3 - 7) and don't want
to set a double standard.  But I would like the expectation to be clearly
set -- the core team has a lot on its plate, and vendor features aren't
part of our critical path right now, so don't expect them to get much
attention from us unless we finish everything else.

There are also several reviews up just to do code cleanup and refactoring
of some base classes. I think we should land these immediately and deal
with any nits in subsequent patches to reduce the queue backlog and speed
up development.


So. Ironic developers and reviewers -- we have a lot of work to do in the
next two months! Is it achievable? I think so.

Do you agree / disagree / with anything I've just said, or have different
priorities? Tell me!


Regards,
Devananda


[1]
http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n58
 [2]
https://review.openstack.org/#/c/70389/2/reference/incubation-integration-requirements
[3] http://russellbryant.net/openstack-stats/ironic-openreviews.html
[4]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-02-11-20.01.log.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140212/4142217d/attachment.html>