<p dir="ltr">I took a look just now at the etherpad and left some initial comments.</p>
<p dir="ltr">Most importantly, I need to clearly restate that ironic is not a fully fledged CMDB.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Let's continue the etherpad and spend some time in Monday's meeting discussing this further.</p>
<p dir="ltr">Regards,</p>
<p dir="ltr">--<br>
Devananda</p>
<div class="gmail_quote">On Mar 21, 2014 10:31 AM, "Vladimir Kozhukalov" <<a href="mailto:vkozhukalov@mirantis.com">vkozhukalov@mirantis.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Guys, <div><br></div><div>I've read comments from JoshNang here <a href="https://etherpad.openstack.org/p/IronicPythonAgent" target="_blank">https://etherpad.openstack.org/p/IronicPythonAgent</a>. 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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Below are some examples of canned flow, generic flow and granular drivers:</div><div><br></div><div>Canned flow driver url: /prepare</div><div>Data: {"key1": "value1", ...}<br></div>
<div>Implementation:<br></div><div>def flow(data):</div><div> ext_mgr.map(lambda ext: <a href="http://ext.name" target="_blank">ext.name</a> == "raid_config", lambda ext: ext.obj(data))</div><div> ext_mgr.map(lambda ext: <a href="http://ext.name" target="_blank">ext.name</a> == "deploy", lambda ext: ext.obj(data))<br>
</div><div> ....</div><div><br></div><div>Canned flow driver url: /deploy</div><div>Data: {"key11": "value11", ...}</div><div>....</div><div><br></div><div>Generic flow driver url: /flow<br></div><div>
Data: [</div><div>{"driver": "prepare", "data": {"key1": "value1", ...}},</div><div>{"driver": "deploy", "data": {"key11": "value11", ...}},<br>
</div><div>{"driver": "power", "data": "reboot"}</div><div>]</div><div>Implemetation:</div><div>def flow(data):</div><div> for d in data:</div><div> ext_mgr.map(lambda ext: <a href="http://ext.name" target="_blank">ext.name</a> == d["driver"], lambda ext: ext.obj(d))</div>
<div><br></div><div><br></div><div>Granual driver driver: /power</div><div>Data: {"key111": "value111", ...}</div><div>Implementation: </div><div>ext_mgr.map(lambda ext: <a href="http://ext.name" target="_blank">ext.name</a> == "power", lambda ext: ext.obj(data))</div>
<div><br></div><div>What do you guys think of having just plain (not tree like) bunch of drivers? </div><div> </div></div><div class="gmail_extra"><br clear="all"><div><div>Vladimir Kozhukalov</div></div>
<br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 1:02 AM, Ryan Petrello <span dir="ltr"><<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@dreamhost.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
---<br>
Ryan Petrello<br>
Senior Developer, DreamHost<br>
<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@dreamhost.com</a><br>
<div><div><br>
On Mar 9, 2014, at 12:10 PM, Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>> wrote:<br>
<br>
> For those looking at Pecan/WSME'fying the agent, some scaffolding was recently added to Pecan which may interest you.<br>
><br>
> <a href="https://review.openstack.org/#/c/78682/" target="_blank">https://review.openstack.org/#/c/78682/</a><br>
><br>
><br>
> -Deva<br>
</div></div><div><div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>