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 :)
STATUS OF THE IRONIC DRIVER --------------------------- 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. https://review.openstack.org/#/c/95024/ 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. https://review.openstack.org/#/c/103164/ (empty init) https://review.openstack.org/#/c/103165/ (scheduler-related bits) https://review.openstack.org/#/c/103167/ (the driver itself) 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. STATUS OF THE UPGRADE PATH -------------------------- 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. https://review.openstack.org/#/c/95025/ 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. https://review.openstack.org/#/c/101920/ https://review.openstack.org/#/c/102563/ QUESTIONS --------- In addition to seeking a spec-freeze-exception for 95025, I would also like some clarification of the requirement to test this upgrade path. 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. 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. 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, since 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. (FWIW, Ironic doesn't pass the tempest/api/compute suite today, but we're working hard on it.) So, I'd like to ask for suggestions on what sort of upgrade testing is reasonable here. I'll toss out two ideas: - 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 - start devstack, load some real data into the nova_bm schema, run the upgrade scripts, then try to deploy an instance with ironic - something else? 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? Regards, Devananda
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev