Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150407/fe49c881/attachment.pgp>