OpenStack Kilo Design Summit has ended
This is the schedule for the Kilo Design Summit, where OpenStack contributors discuss the future of OpenStack development.
Click here for the main OpenStack Summit conference schedule.

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Ironic [clear filter]
Wednesday, November 5

09:00 CET

Exposing different capabilities in Ironic
Boot and deploy driver behavior differs in ways which are not exposed nor discoverable in the API. Such differences are a break in the abstraction layer that Ironic provides, representing either a deficiency in a driver or in our API.

Vendor drivers naturally differ in their capabilities. The touch point for such capabilities are hidden either within the vendor passthru API endpoint, or nestled within special node properties or driver_info which only that driver can interpret. Neither approach is discoverable by a client.

In a heterogeneous environment, how does Ironic expose these differences to Nova and to users?

Hint: it is possible to use node.properties.capabilities to expose hints to the Nova scheduler, but this is not standardized, nor automatic, nor well documented, nor easily interpretable by a direct user.

Wednesday November 5, 2014 09:00 - 09:40 CET
Dufy Le Meridien

09:50 CET

Resource locking in Ironic
I wrote the TaskManager module to protect hardware operations from interruption in a distributed environment, but it's not perfect. A crashed Conductor can leave dangling locks that still require manual intervention to free; we haven't added automatic expiration to locks because some operations rightfully take a long time. Meanwhile, client requests get refused when a node is locked, regardless of what operation holds the lock. Even internal periodic jobs like sync_power_state take a lock, which can result in users getting unexpected NodeLocked errors.

Have we gone too far away from the original intent? Are we using locks too broadly, or do we need more fine-grained lock handling (types or reasons or duration-based locks)? Or should we simply make it easier for operators to manually release a lock, eg. by adding a REST verb to "unlock" a node?

Wednesday November 5, 2014 09:50 - 10:30 CET
Dufy Le Meridien

11:00 CET

Making Ironic Easier to Use
We all agree Ironic should be easier to use "stand alone". Let's nail down a timeline for some concrete improvements on this.

Relates to in-project functional testing.

Wednesday November 5, 2014 11:00 - 11:40 CET
Dufy Le Meridien

11:50 CET

Understanding the hardware we have
Even though we have not agreed [1] whether to call it introspection, interrogation, inventory, or analysis, there is general agreement that this functionality is essential to Ironic AND discrete from the process of locating new (unmanaged) hardware within a data center.

We had several competing proposals [2] for implementing this, and a proof-of-concept [3]. Given the intense interest in this feature, I would like this feature to be implemented during Kilo, but that requires a solution which accommodates both in- and out-of-band methods within a common API.




Wednesday November 5, 2014 11:50 - 12:30 CET
Dufy Le Meridien
Thursday, November 6

09:00 CET

Asserting hardware ready-state
Discuss a unified API for asserting ready state using either in-band and out-of-band means.


Hardware usually needs to be prepared before its first use. In many environments, the same process is repeated before each use. OnMetal already supports a "decom" phase (though somewhat of a misnomer, this is all about "ready-state").

That work has not landed upstream yet. However, the OnMetal team is giving a presentation on Wednesday about it:


Thursday November 6, 2014 09:00 - 09:40 CET
Friday, November 7

13:40 CET

Ironic contributors meetup
The contributors meetup is a informal gathering of the project contributors, with an open agenda.

Friday November 7, 2014 13:40 - 17:10 CET