<div dir="ltr">And here is scheme <a href="https://drive.google.com/a/mirantis.com/file/d/0B-Olcp4mLLbvRks0eEhvMXNPM3M/edit?usp=sharing">https://drive.google.com/a/mirantis.com/file/d/0B-Olcp4mLLbvRks0eEhvMXNPM3M/edit?usp=sharing</a><br>
</div><div class="gmail_extra"><br clear="all"><div><div>Vladimir Kozhukalov</div></div>
<br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 9:16 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@mirantis.com</a>></span> wrote:<br><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><span class="HOEnZb"><font color="#888888"><div> </div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all">
<div><div>Vladimir Kozhukalov</div></div></font></span><div><div class="h5">
<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></div></div>
</blockquote></div><br></div>