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


___
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
ryan.petre...@dreamhost.comwrote:

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


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


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
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 russellhaer...@gmail.comwrote:

 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


___
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
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 
 russellhaer...@gmail.comwrote:

 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



 

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 http://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 
russellhaer...@gmail.com 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
vkozhuka...@mirantis.com 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
devananda@gmail.com 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