Open Stack

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" <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
>>
>
>
> _______________________________________________
> 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/20140323/3ff9053c/attachment.html>