Open Stack

Hi all,

I'd like to announce my candidacy as PTL for Ironic for the Liberty cycle.
I've been involved in OpenStack since the Essex cycle, and have served as
PTL for Ironic since I started the project at the Havana summit. As the
project has matured, my day-to-day activity within the project has changed
from writing code to mentoring to enabling subteams. Recently, I have begun
to spend more time on projects within my employer; while I expect that to
continue, the two roles complement each other and, as such, I would like to
continue to serve as PTL for another cycle.

I'd like to thank everyone who continues to lend their knowledge, hard
work, and humor to making this project successful and this community
enjoyable to work with.

Looking back at the Juno release, we saw integration with Nova and many new
hardware drivers in Ironic. During Kilo, we have had minimal changes to the
nova.virt.ironic driver, and only two new hardware drivers. On the other
hand, we've had many changes within Ironic and implemented several features
which align with the goals which I set out at the beginning of the cycle.

In the day-to-day pace of staring at review boards and patches that haven't
merged yet, we often get frustrated because it feels like things don't move
fast enough. When I look back at the last six months, the picture looks
different. I think we have accomplished a lot, and I believe that is a
result of empowering sub-teams and building stable APIs between services
and libraries. I'd like to highlight a few of the biggest accomplishments.

As a result of discussions at the Paris design summit, we spent a hefty
chunk of the cycle designing and implementing a finite state machine [1] to
formally model the transitions between node states. We then implemented
support for two of the new state transitions (introspection and cleaning).

This exposed a flaw in the pre-Kilo node states which we've addressed, but
that change caused us to rev the API in an incompatible way. To maintain
compatibility with Juno-era clients, we borrowed from Nova's lead with API
microversions and implemented support [2] for those as well. Even so, this
change led to more friction than any other change in Ironic during this
cycle, and is a good reminder that building a stable API is possibly the
most important thing we do.

We gave drivers the ability to maintain internal state in the database and
to register their own periodic tasks, and we added iRMC (Fujitsu) and AMT
(Intel) drivers. We also continue to hold to our guarantee of
backwards-compatibility at the driver API layer, which has led to more than
one out-of-tree driver cropping up. It has also led to some driver
developers publishing new libraries for their hardware, and plugging those
in to Ironic with relatively little effort. [3] For the record, I think
that's fantastic, and we should continue enabling that. The proliantutils
[4] project is just one example of this; several others are being developed
elsewhere and released to pypi by their vendors.

The ironic-python-agent [5] project has been around for just over a year
now, and I'm very pleased both with the project and the team integration.
The ironic-discoverd project [6] is just over six months old; devstack
support is in the works and so I hope that by the end of the Liberty cycle,
it will be integrated and tested alongside with Ironic. Even more recently,
the bifrost project [7] was created to demonstrate the functionality of a
stand-alone Ironic service and simplify small-scale hardware deployment. As
it turns out, this is a convenient way to do functional testing of Ironic
without a full OpenStack deployment, so we'll be exploring that in Liberty.

I'm sure I've left some things out - this really isn't the place for full
release notes anyway :)

In Liberty, I'd like us to complete the state machine, split the boot and
deploy interfaces, and complete the client side of client-server version
negotiation. That's enough changes in the core of the project for one cycle.

I'd like to see more consistency in feature coverage across hardware
drivers, as well as better tracking and communication about each drivers'
capabilities.

We need to keep abreast of changes in the horizontal efforts across
OpenStack -- oslo, qa, and docs. In particular, we will need to look at the
move to in-tree functional testing and determine how we want to structure
that for ourselves. We also have no presence in the OpenStack Manual,
though our developer docs have sprouted several pages geared towards
operators [8]. Whether our operator-centric docs stay in the code tree or
are moved elsewhere, we should continue to develop them.

As the contributor base grows, we may need to re-evaluate the team
structure, but right now I think things are going well in this area. I plan
to continue guiding us in a similar direction in Liberty while engaging
with the broader community and learning from the scaling challenges facing
OpenStack as a whole.


Thanks for your consideration and support,
Devananda



[1]
http://specs.openstack.org/openstack/ironic-specs/specs/kilo/new-ironic-state-machine.html
[2]
http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html
[3]
http://lists.openstack.org/pipermail/openstack-dev/2015-February/058010.html
[4] https://github.com/stackforge/proliantutils
[5] http://docs.openstack.org/developer/ironic-python-agent/
[6] https://github.com/stackforge/ironic-discoverd
[7] https://github.com/juliakreger/bifrost
[8] http://docs.openstack.org/developer/ironic/#admin-guide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150407/76561fae/attachment.html>