Open Stack

Russell,

Great to hear you are going to move towards Pecan+WSME. Yesterday I had a
look at teeth projects. Next few days I am going to start contributing.
First of all, I think, we need to arrange all that stuff about pluggable
architecture. I've created a wiki page about Ironic python agent
https://wiki.openstack.org/wiki/Ironic-python-agent.

And the question about contributing. Have you managed to send pull request
to openstack-infra in order to move this project into github.com/stackforge?
Or we are supposed to arrange 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 <russellhaering at gmail.com>wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20140308/f06276ee/attachment.html>