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

2014-03-23 Thread Devananda van der Veen 
I took a look just now at the etherpad and left some initial comments.

Most importantly, I need to clearly restate that ironic is not a fully
fledged CMDB.

Though it may intersect with a subset of CMDB functionality, this is merely
to have enough data to provision hardware on demand. Also, ironic can not
depend on a CMDB service, which does not exist in OpenStack; the same goes
for ironic-python-agent. I'd like to understand why those items were added
to this proposal. If you need to expose HW info to an external cmdb (which
I expect many deployers will) this can be done by stashing the needed info
in a common format in a field that ironic does not introspect (eg,
nodes.extra) and allowing the cmdb to retrieve it from ironic's api.

As far as procedural vs declarative API, I don't know that we had any
agreement on this in Sunnyvale. IIUC, Viktor's point is that the agent
should expose a granular procedural API which could be driven by ir-cond or
by complex flows in the agent. My proposal was for a declarative API by
which ironic could pass a flow to the agent, which would then apply it
asynchronously. These seem compatible to me.

Let's continue the etherpad and spend some time in Monday's meeting
discussing this further.

Regards,

--
Devananda
On Mar 21, 2014 10:31 AM, "Vladimir Kozhukalov" 
wrote:

> Guys,
>
> I've read comments from JoshNang here
> https://etherpad.openstack.org/p/IronicPythonAgent. And it looks like we
> are still not on the same page about architecture of agent. I'd like us to
> avoid having hard coded logic in agent at all. If we need, then let's
> implement it as a driver. I mean it would be great to have all pieces of
> functionality as and only as drivers exposed via REST.
>
> For example, I have simple granular drivers, let say "power state" driver
> and "disk setup" driver and I'd like it to be possible to call them
> independently (granularly) outside of any kind of flow, outside of
> "prepare" or "deploy" or any other stages. There is no reason to put
> granular actions inside "deploy" or "prepare" stages w/o exposing them
> directly via REST.
>
> On the other hand, we obviously need to have flows (sequences of granular
> tasks), but I'd like to see them implemented as drivers as well. We can
> have canned flows (hard coded sequences like "prepare" and "deploy") as
> well as fully data driven generic flow driver. And we obviously need to get
> rid of "modes" so as to have just a plain bunch of drivers which are able
> to call their neighbors if necessary.
>
> Below are some examples of canned flow, generic flow and granular drivers:
>
> Canned flow driver url:  /prepare
> Data: {"key1": "value1", ...}
> Implementation:
> def flow(data):
>   ext_mgr.map(lambda ext: ext.name == "raid_config", lambda ext:
> ext.obj(data))
>   ext_mgr.map(lambda ext: ext.name == "deploy", lambda ext: ext.obj(data))
>   
>
> Canned flow driver url: /deploy
> Data: {"key11": "value11", ...}
> 
>
> Generic flow driver url: /flow
> Data: [
> {"driver": "prepare", "data": {"key1": "value1", ...}},
> {"driver": "deploy", "data": {"key11": "value11", ...}},
> {"driver": "power", "data": "reboot"}
> ]
> Implemetation:
> def flow(data):
>   for d in data:
>  ext_mgr.map(lambda ext: ext.name == d["driver"], lambda ext:
> ext.obj(d))
>
>
> Granual driver driver: /power
> Data: {"key111": "value111", ...}
> Implementation:
> ext_mgr.map(lambda ext: ext.name == "power", lambda ext: ext.obj(data))
>
> What do you guys think of having just plain (not tree like) bunch of
> drivers?
>
>
> Vladimir Kozhukalov
>
>
> On Mon, Mar 10, 2014 at 1:02 AM, Ryan Petrello <
> ryan.petre...@dreamhost.com> wrote:
>
>> FYI, the API scaffolding isn't actually released yet, though I'm planning
>> on making a pecan release with this in the next week or two.
>>
>> ---
>> Ryan Petrello
>> Senior Developer, DreamHost
>> ryan.petre...@dreamhost.com
>>
>> On Mar 9, 2014, at 12:10 PM, Devananda van der Veen <
>> devananda@gmail.com> wrote:
>>
>> > For those looking at Pecan/WSME'fying the agent, some scaffolding was
>> recently added to Pecan which may interest you.
>> >
>> > https://review.openstack.org/#/c/78682/
>> >
>> >
>> > -Deva
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-21 Thread Jay Faulkner 
On 3/21/14, 10:18 AM, Vladimir Kozhukalov wrote:
> And here is scheme
> https://drive.google.com/a/mirantis.com/file/d/0B-Olcp4mLLbvRks0eEhvMXNPM3M/edit?usp=sharing
>

Vlamimir, can you recreate this drawing in a format that doesn't require
an additional browser plugin? Thanks.

-Jay





signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-21 Thread Vladimir Kozhukalov 
And here is scheme
https://drive.google.com/a/mirantis.com/file/d/0B-Olcp4mLLbvRks0eEhvMXNPM3M/edit?usp=sharing

Vladimir Kozhukalov


On Fri, Mar 21, 2014 at 9:16 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Guys,
>
> I've read comments from JoshNang here
> https://etherpad.openstack.org/p/IronicPythonAgent. And it looks like we
> are still not on the same page about architecture of agent. I'd like us to
> avoid having hard coded logic in agent at all. If we need, then let's
> implement it as a driver. I mean it would be great to have all pieces of
> functionality as and only as drivers exposed via REST.
>
> For example, I have simple granular drivers, let say "power state" driver
> and "disk setup" driver and I'd like it to be possible to call them
> independently (granularly) outside of any kind of flow, outside of
> "prepare" or "deploy" or any other stages. There is no reason to put
> granular actions inside "deploy" or "prepare" stages w/o exposing them
> directly via REST.
>
> On the other hand, we obviously need to have flows (sequences of granular
> tasks), but I'd like to see them implemented as drivers as well. We can
> have canned flows (hard coded sequences like "prepare" and "deploy") as
> well as fully data driven generic flow driver. And we obviously need to get
> rid of "modes" so as to have just a plain bunch of drivers which are able
> to call their neighbors if necessary.
>
> Below are some examples of canned flow, generic flow and granular drivers:
>
> Canned flow driver url:  /prepare
> Data: {"key1": "value1", ...}
> Implementation:
> def flow(data):
>   ext_mgr.map(lambda ext: ext.name == "raid_config", lambda ext:
> ext.obj(data))
>   ext_mgr.map(lambda ext: ext.name == "deploy", lambda ext: ext.obj(data))
>   
>
> Canned flow driver url: /deploy
> Data: {"key11": "value11", ...}
> 
>
> Generic flow driver url: /flow
> Data: [
> {"driver": "prepare", "data": {"key1": "value1", ...}},
> {"driver": "deploy", "data": {"key11": "value11", ...}},
> {"driver": "power", "data": "reboot"}
> ]
> Implemetation:
> def flow(data):
>   for d in data:
>  ext_mgr.map(lambda ext: ext.name == d["driver"], lambda ext:
> ext.obj(d))
>
>
> Granual driver driver: /power
> Data: {"key111": "value111", ...}
> Implementation:
> ext_mgr.map(lambda ext: ext.name == "power", lambda ext: ext.obj(data))
>
> What do you guys think of having just plain (not tree like) bunch of
> drivers?
>
>
> Vladimir Kozhukalov
>
>
> On Mon, Mar 10, 2014 at 1:02 AM, Ryan Petrello <
> ryan.petre...@dreamhost.com> wrote:
>
>> FYI, the API scaffolding isn't actually released yet, though I'm planning
>> on making a pecan release with this in the next week or two.
>>
>> ---
>> Ryan Petrello
>> Senior Developer, DreamHost
>> ryan.petre...@dreamhost.com
>>
>> On Mar 9, 2014, at 12:10 PM, Devananda van der Veen <
>> devananda@gmail.com> wrote:
>>
>> > For those looking at Pecan/WSME'fying the agent, some scaffolding was
>> recently added to Pecan which may interest you.
>> >
>> > https://review.openstack.org/#/c/78682/
>> >
>> >
>> > -Deva
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-21 Thread Vladimir Kozhukalov 
Guys,

I've read comments from JoshNang here
https://etherpad.openstack.org/p/IronicPythonAgent. And it looks like we
are still not on the same page about architecture of agent. I'd like us to
avoid having hard coded logic in agent at all. If we need, then let's
implement it as a driver. I mean it would be great to have all pieces of
functionality as and only as drivers exposed via REST.

For example, I have simple granular drivers, let say "power state" driver
and "disk setup" driver and I'd like it to be possible to call them
independently (granularly) outside of any kind of flow, outside of
"prepare" or "deploy" or any other stages. There is no reason to put
granular actions inside "deploy" or "prepare" stages w/o exposing them
directly via REST.

On the other hand, we obviously need to have flows (sequences of granular
tasks), but I'd like to see them implemented as drivers as well. We can
have canned flows (hard coded sequences like "prepare" and "deploy") as
well as fully data driven generic flow driver. And we obviously need to get
rid of "modes" so as to have just a plain bunch of drivers which are able
to call their neighbors if necessary.

Below are some examples of canned flow, generic flow and granular drivers:

Canned flow driver url:  /prepare
Data: {"key1": "value1", ...}
Implementation:
def flow(data):
  ext_mgr.map(lambda ext: ext.name == "raid_config", lambda ext:
ext.obj(data))
  ext_mgr.map(lambda ext: ext.name == "deploy", lambda ext: ext.obj(data))
  

Canned flow driver url: /deploy
Data: {"key11": "value11", ...}


Generic flow driver url: /flow
Data: [
{"driver": "prepare", "data": {"key1": "value1", ...}},
{"driver": "deploy", "data": {"key11": "value11", ...}},
{"driver": "power", "data": "reboot"}
]
Implemetation:
def flow(data):
  for d in data:
 ext_mgr.map(lambda ext: ext.name == d["driver"], lambda ext:
ext.obj(d))


Granual driver driver: /power
Data: {"key111": "value111", ...}
Implementation:
ext_mgr.map(lambda ext: ext.name == "power", lambda ext: ext.obj(data))

What do you guys think of having just plain (not tree like) bunch of
drivers?


Vladimir Kozhukalov


On Mon, Mar 10, 2014 at 1:02 AM, Ryan Petrello
wrote:

> FYI, the API scaffolding isn't actually released yet, though I'm planning
> on making a pecan release with this in the next week or two.
>
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petre...@dreamhost.com
>
> On Mar 9, 2014, at 12:10 PM, Devananda van der Veen <
> devananda@gmail.com> wrote:
>
> > For those looking at Pecan/WSME'fying the agent, some scaffolding was
> recently added to Pecan which may interest you.
> >
> > https://review.openstack.org/#/c/78682/
> >
> >
> > -Deva
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-09 Thread Ryan Petrello 
FYI, the API scaffolding isn’t actually released yet, though I’m planning on 
making a pecan release with this in the next week or two.

---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com

On Mar 9, 2014, at 12:10 PM, Devananda van der Veen  
wrote:

> For those looking at Pecan/WSME'fying the agent, some scaffolding was 
> recently added to Pecan which may interest you.
> 
> https://review.openstack.org/#/c/78682/
> 
> 
> -Deva
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-09 Thread Devananda van der Veen 
For those looking at Pecan/WSME'fying the agent, some scaffolding was
recently added to Pecan which may interest you.

https://review.openstack.org/#/c/78682/


-Deva
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-07 Thread Jay Faulkner 

Vladimir,

I just put up https://review.openstack.org/#/c/79088/ for review to get 
the teeth-agent imported into openstack. I'm not sure if we want this 
merged immediately or if we want to get the outstanding non-Openstack 
dependencies settled before then, but hopefully this can help get things 
started.


--
Jay Faulkner

On 3/7/14, 12:53 PM, Vladimir Kozhukalov wrote:

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 
mailto:russellhaer...@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
mailto:vkozhuka...@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
mailto:devananda@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 speci

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

2014-03-07 Thread Russell Haering 
Thanks for putting that info together!

I'm not sure exactly what order things need to happen in, but Jay (JayF) is
working on the infra bits of getting a repository and CI, and Jim (jroll)
is getting the Pecan+WSME part done. Hopefully we'll have it all ready by
Monday.

On Fri, Mar 7, 2014 at 12:53 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> 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 
> 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 <
>> vkozhuka...@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@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@lists

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

2014-03-07 Thread Vladimir Kozhukalov 
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 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 <
> vkozhuka...@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@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@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__

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 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 <
vkozhuka...@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@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@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-03-07 Thread Vladimir Kozhukalov 
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@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev