Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/6822aaf9/attachment.html>