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
