<div dir="ltr"><font face="courier new, monospace">This topic was raised in today's Nova meeting. I'll attempt a summary. I'm also on a train right now, and trying to get this done before I get off the train :)</font><div>
<font face="courier new, monospace"><br></font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">STATUS OF THE IRONIC DRIVER</font></div><div><font face="courier new, monospace">---------------------------</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Merging the nova.virt.ironic driver into Nova is high priority for Juno for a lot of reasons (which I won't repeat). Several members of nova-core have expressed their agreement on this. The Nova spec for this has been approved.</font></div>
<div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/95024/">https://review.openstack.org/#/c/95024/</a></font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">The nova.virt.ironic driver code has been proposed in three patches, by copying the code that's in Ironic's tree and changing import paths. We are actively taking the feedback given on those patches, incorporating into Ironic, and re-submitting the patches with those changes included. It's laborious, but this is the process we agreed upon at the summit, and so far, the feedback has been helpful and constructive.</font></div>
<div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/103164/">https://review.openstack.org/#/c/103164/</a> (empty init)</font></div><div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/103165/">https://review.openstack.org/#/c/103165/</a> (scheduler-related bits)</font></div>
<div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/103167/">https://review.openstack.org/#/c/103167/</a> (the driver itself)</font></div><div><font face="courier new, monospace"><br></font></div>
<div><font face="courier new, monospace">That code, in Ironic's tree, has been stably tested by tempest for all of the Juno cycle. Additional work is ongoing to significantly improve that testing; this has been the focus of our testing efforts this cycle.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">STATUS OF THE UPGRADE PATH<br></font></div><div><font face="courier new, monospace">--------------------------</font></div>
<div><font face="courier new, monospace"><br></font></div><div><div><font face="courier new, monospace">As discussed at the Juno summit, the Nova team, and some members of the TC, despite my objections, feel that an upgrade path from nova.virt.baremetal to nova.virt.ironic is important. The Nova spec for this has not yet been approved, but has been proposed for a spec-freeze exception. This email is a status report and request for such an exception.</font></div>
<div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/95025/">https://review.openstack.org/#/c/95025/</a></font></div><div><font face="courier new, monospace"><br></font></div></div><div><font face="courier new, monospace">The tools described in the upgrade spec have been proposed to Nova, but not yet reviewed. I have not personally tested them or reviewed them thoroughly, and among all the other things planned in the next few weeks, this honestly wasn't high on my radar until today.</font></div>
<div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/101920/">https://review.openstack.org/#/c/101920/</a></font></div><div><font face="courier new, monospace"> <a href="https://review.openstack.org/#/c/102563/">https://review.openstack.org/#/c/102563/</a></font></div>
<div><br></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">QUESTIONS</font></div><div><font face="courier new, monospace">---------</font></div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace">In addition to seeking a spec-freeze-exception for 95025, I would also like some clarification of the requirement to test this upgrade path. </font><span style="font-family:'courier new',monospace">Some nova-core folks have pointed out that they do not want to accept the nova.virt.ironic driver until the upgrade path from nova.virt.baremetal *has test coverage*, but what that means is not clear to me. It's been suggested that we use grenade (I am pretty sure Sean suggested this at the summit, and I wrote it into my spec proposal soon thereafter). After looking into grenade, I don't think it is the right tool to test with, and I'm concerned that no one pointed this out sooner.</span></div>
<div><span style="font-family:'courier new',monospace"><br></span></div><div><span style="font-family:'courier new',monospace">Philosophically, this isn't an upgrade of one service from version X to Y. It's a replacement of one nova driver with a completely different driver. As I understand it, that's not what grenade is for. But maybe I'm wrong on this, or maybe it's flexible.</span></div>
<div><span style="font-family:'courier new',monospace"><br></span></div><div><font face="courier new, monospace">I also have a technical objection: even if devstack can start and properly configure nova.virt.baremteal (which I doubt, because it isn't tested at all), it is going to fail the tempest/api/compute test suite horribly. The baremetal driver never passed tempest, and never had devstack-gate support. This matters because grenade uses tempest to validate a stack pre- and post-upgrade. Therefore, s</font><span style="font-family:'courier new',monospace">ince we know that the old code is going to fail tempest, requiring grenade testing as a precondition to accepting the ironic driver effectively means we need to go develop the baremetal driver to a point it could pass tempest. I'm going to assume no one is actually suggesting that, and instead believe that none of us thought this through.</span></div>
<div><span style="font-family:'courier new',monospace"><br></span></div><div><span style="font-family:'courier new',monospace">(FWIW, Ironic doesn't pass the tempest/api/compute suite today, but we're working hard on it.)</span></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">So, I'd like to ask for suggestions on what sort of upgrade testing is reasonable here. I'll toss out two ideas:</font></div>
<div><font face="courier new, monospace">- load some fake data into the nova_bm schema, run the upgrade scripts, start ironic, issue some API queries, and see if the data's correct</font></div><div><font face="courier new, monospace">- start devstack, </font><span style="font-family:'courier new',monospace">load some real data into the nova_bm schema,</span><span style="font-family:'courier new',monospace"> </span><span style="font-family:'courier new',monospace">run the upgrade scripts, then try to deploy an instance with ironic</span></div>
<div><font face="courier new, monospace">- something else?</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">The first should be simple to implement; the second would be slightly more complex, but I don't think it's terrible. However, I do not know where to put either of these as they don't appear to fit cleanly into any QA project I know of, nor into a project's unit test suite. Maybe devstack/exercises?</font></div>
</div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Regards,</font></div><div><font face="courier new, monospace">Devananda</font></div>
</div>