<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><div class="h5">Hello ironic developers, tripleo folks, and interested third-parties!<div><br></div><div>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.</div>
</div></div><div><div><div class="h5"><div><br></div><div><br></div><div>We have four areas inside of Ironic that need significant movement in order to graduate this cycle:<br></div><div><br></div><div>* Critical & High priority bugs<br>
</div>
<div> 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.</div>
<div><br></div><div>* Missing functionality<br></div><div> 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.</div><div>
<br></div><div> <a href="https://blueprints.launchpad.net/ironic/+spec/serial-console-access" target="_blank">https://blueprints.launchpad.net/ironic/+spec/serial-console-access</a></div><div> I believe some folks are using this, even though the TripleO team is not, and I personally never used the feature in Nova baremetal.</div>
<div> 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.</div><div> <a href="https://blueprints.launchpad.net/ironic/+spec/preserve-ephemeral" target="_blank">https://blueprints.launchpad.net/ironic/+spec/preserve-ephemeral</a></div>
<div> 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.</div><div><br></div><div>* Testing & QA</div>
<div> 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?</div>
<div><br></div><div>* Documentation</div><div> 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.</div><div><br>
</div><div><br></div><div>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:<br>
</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">"[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."</blockquote>
<div><br></div><div><br></div><div>We have two blueprints up that pertain specifically to this requirement:<br></div><div><div><br></div><div><a href="https://blueprints.launchpad.net/nova/+spec/deprecate-baremetal-driver" target="_blank">https://blueprints.launchpad.net/nova/+spec/deprecate-baremetal-driver</a><br>
</div></div><div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><a href="https://blueprints.launchpad.net/ironic/+spec/migration-from-nova" target="_blank">https://blueprints.launchpad.net/ironic/+spec/migration-from-nova</a><br></div></div><div><br></div><div>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....</div>
</div><div><br></div><div><br></div><div>That's it for the graduation-critical tasks, but that's not all the work currently in our review queue or targeted to I3 ...</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div></div></div><div>So. Ironic developers and reviewers -- we have a lot of work to do in the next two months! Is it achievable? I think so.</div><div><br></div><div>Do you agree / disagree / with anything I've just said, or have different priorities? Tell me!</div>
<div><br></div><div class=""><div><br></div><div>Regards,</div><div>Devananda</div><div><br></div><div><br></div><div>[1] <a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n58" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n58</a><br>
</div>
<div>[2] <a href="https://review.openstack.org/#/c/70389/2/reference/incubation-integration-requirements" target="_blank">https://review.openstack.org/#/c/70389/2/reference/incubation-integration-requirements</a></div><div>
[3] <a href="http://russellbryant.net/openstack-stats/ironic-openreviews.html">http://russellbryant.net/openstack-stats/ironic-openreviews.html</a></div><div>
[4] <a href="http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-02-11-20.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-02-11-20.01.log.html</a></div></div></div></div></div></div>
</div></div>