[openstack-dev] [Ironic] [TripleO] Goal setting // progress towards integration

Michael Still mikal at stillhq.com
Wed Feb 12 20:21:46 UTC 2014


On Wed, Feb 12, 2014 at 12:40 PM, Devananda van der Veen
<devananda.vdv at gmail.com> wrote:

[snip]

> 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.

I would also like to see CI (either third party or in the gate) for
the nova driver before merging it. There's a chicken and egg problem
here if its in the gate, but I'd like to see it at least proposed as a
review.

Michael

-- 
Rackspace Australia



More information about the OpenStack-dev mailing list