Re: [openstack-dev] [Ironic] A ramdisk agent

2014-03-07 Thread Russell Haering
Vladmir, Hey, I'm on the team working on this agent, let me offer a little history. We were working on a system of our own for managing bare metal gear which we were calling Teeth. The project was mostly composed of: 1. teeth-agent: an on-host provisioning agent 2. teeth-overlord: a centralized

Re: [openstack-dev] [Ironic] A ramdisk agent

2014-03-07 Thread Russell Haering
everything (werkzeug - Pecan/WSME, architectural questions) before we move this agent to stackforge? Vladimir Kozhukalov On Fri, Mar 7, 2014 at 8:53 PM, Russell Haering russellhaer...@gmail.comwrote: Vladmir, Hey, I'm on the team working on this agent, let me offer a little

[openstack-dev] [Ironic] Nodeless Vendor Passthru API

2014-03-24 Thread Russell Haering
All, Ironic allows drivers to expose a vendor passthru API on a Node. This basically serves two purposes: 1. Allows drivers to expose functionality that hasn't yet been standardized in the Ironic API. For example, the Seamicro driver exposes attach_volume, set_boot_device and set_node_vlan_id

Re: [openstack-dev] [Ironic] Nodeless Vendor Passthru API

2014-03-25 Thread Russell Haering
On Tue, Mar 25, 2014 at 6:56 AM, Lucas Alvares Gomes lucasago...@gmail.comwrote: Hi Russell, Ironic allows drivers to expose a vendor passthru API on a Node. This basically serves two purposes: 1. Allows drivers to expose functionality that hasn't yet been standardized in the Ironic API.

Re: [openstack-dev] [Ironic] Merging the agent driver

2014-04-16 Thread Russell Haering
All, If anyone has a chance to do some review, we really want to get this one merged: https://review.openstack.org/#/c/81919/ This will clear the way for us to work on getting the driver reviewed, followed by a series of smaller patches. Thanks, Russell On Tue, Apr 8, 2014 at 4:58 PM, Jim

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

2014-04-17 Thread Russell Haering
Completely agree. We're spending too much time discussing features after they're implemented, which makes contribution more difficult for everyone. Forcing an explicit design+review process, using the same tools as we use for coding+review seems like a great idea. If it doesn't work we can

Re: [openstack-dev] [Ironic] Moving to a formal design process

2014-05-19 Thread Russell Haering
+1 to this process, and I think the template is pretty reasonable. One thing to call out maybe, is are there any known failure scenarios? If so, why shouldn't they block the spec? On Mon, May 19, 2014 at 5:51 PM, Devananda van der Veen devananda@gmail.com wrote: Added -

Re: [openstack-dev] [Ironic][Neutron] - Integration with neutron using external attachment point

2014-05-20 Thread Russell Haering
We've been experimenting some with how to use Neutron with Ironic here at Rackspace. Our very experimental code: https://github.com/rackerlabs/ironic-neutron-plugin Our objective is the same as what you're describing, to allow Nova servers backed by Ironic to attach to arbitrary Neutron