Open Stack

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 <
vkozhukalov at 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.petrello at 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.petrello at dreamhost.com
>>
>> On Mar 9, 2014, at 12:10 PM, Devananda van der Veen <
>> devananda.vdv at 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 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/20140321/2f427403/attachment.html>