confirmed On 04/07/2015 06:58 AM, Devananda van der Veen wrote: > 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 > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
