[openstack-dev] [Ironic] Should we adopt a blueprint design process

Devananda van der Veen devananda.vdv at gmail.com
Thu Apr 17 17:11:19 UTC 2014


Hi all,

The discussion of blueprint review has come up recently for several
reasons, not the least of which is that I haven't yet reviewed many of the
blueprints that have been filed recently.

My biggest issue with launchpad blueprints is that they do not provide a
usable interface for design iteration prior to writing code. Between the
"whiteboard" section, wikis, and etherpads, we have muddled through a few
designs (namely cinder and ceilometer integration) with accuracy, but the
vast majority of BPs are basically reviewed after they're implemented. This
seems to be a widespread objection to launchpad blueprints within the
OpenStack community, which others are trying to solve. Having now looked at
what Nova is doing with the nova-specs repo, and considering that TripleO
is also moving to that format for blueprint submission, and considering
that we have a very good "review things in gerrit" culture in the Ironic
community already, I think it would be a very positive change.

For reference, here is the Nova discussion thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html

and the specs repo BP template:
https://github.com/openstack/nova-specs/blob/master/specs/template.rst

So, I would like us to begin using this development process over the course
of Juno. We have a lot of BPs up right now that are light on details, and,
rather than iterate on each of them in launchpad, I would like to propose
that:
* we create an ironic-specs repo, based on Nova's format, before the summit
* I will begin reviewing BPs leading up to the summit, focusing on features
that were originally targeted to Icehouse and didn't make it, or are
obviously achievable for J1
* we'll probably discuss blueprints and milestones at the summit, and will
probably adjust targets
* after the summit, for any BP not targeted to J1, we require blueprint
proposals to go through the spec review process before merging any
associated code.

Cores and interested parties, please reply to this thread with your
opinions.

--
Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/cd61a4a1/attachment.html>


More information about the OpenStack-dev mailing list