Open Stack

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 automation mechanism

Plus a few other libraries (including teeth-rest, which contains some
common code we factored out of the agent/overlord).

A few weeks back we decided to shift our focus to using Ironic. At this
point we have effectively abandoned teeth-overlord, and are instead
focusing on upstream Ironic development, continued agent development and
building an Ironic driver capable of talking to our agent.

Over the last few days we've been removing non-OS-approved dependencies
from our agent: I think teeth-rest (and werkzeug, which it depends on) will
be the last to go when we replace it with Pecan+WSME sometime in the next
few days.

Thanks,
Russell


On Fri, Mar 7, 2014 at 8:26 AM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:

> As far as I understand, there are 4 projects which are connected with this
> topic. Another two projects which were not mentioned by Devananda are
> https://github.com/rackerlabs/teeth-rest
> https://github.com/rackerlabs/teeth-overlord
>
> Vladimir Kozhukalov
>
>
> On Fri, Mar 7, 2014 at 4:41 AM, Devananda van der Veen <
> devananda.vdv at gmail.com> wrote:
>
>> All,
>>
>> The Ironic team has been discussing the need for a "deploy agent" since
>> well before the last summit -- we even laid out a few blueprints along
>> those lines. That work was deferred  and we have been using the same deploy
>> ramdisk that nova-baremetal used, and we will continue to use that ramdisk
>> for the PXE driver in the Icehouse release.
>>
>> That being the case, at the sprint this week, a team from Rackspace
>> shared work they have been doing to create a more featureful hardware agent
>> and an Ironic driver which utilizes that agent. Early drafts of that work
>> can be found here:
>>
>> https://github.com/rackerlabs/teeth-agent
>> https://github.com/rackerlabs/ironic-teeth-driver
>>
>> I've updated the original blueprint and assigned it to Josh. For
>> reference:
>>
>> https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk
>>
>> I believe this agent falls within the scope of the baremetal provisioning
>> program, and welcome their contributions and collaboration on this. To that
>> effect, I have suggested that the code be moved to a new OpenStack project
>> named "openstack/ironic-python-agent". This would follow an independent
>> release cycle, and reuse some components of tripleo (os-*-config). To keep
>> the collaborative momentup up, I would like this work to be done now (after
>> all, it's not part of the Ironic repo or release). The new driver which
>> will interface with that agent will need to stay on github -- or in a
>> gerrit feature branch -- until Juno opens, at which point it should be
>> proposed to Ironic.
>>
>> The agent architecture we discussed is roughly:
>> - a pluggable JSON transport layer by which the Ironic driver will pass
>> information to the ramdisk. Their initial implementation is a REST API.
>> - a collection of hardware-specific utilities (python modules, bash
>> scripts, what ever) which take JSON as input and perform specific actions
>> (whether gathering data about the hardware or applying changes to it).
>> - and an agent which routes the incoming JSON to the appropriate utility,
>> and routes the response back via the transport layer.
>>
>>
>> -Devananda
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140307/1c55c4a4/attachment.html>