Open Stack

Hi,

as for execution of arbitrary code across the OpenStack cluster - I was
thinking of mcollective + fact filters:

1) we need to start using mcollective facts [0] [2] - we don't
use/configure this currently
2) use mcollective execute_shell_command agent (or any other agent) with
fact filter [1]

So, for example, if we have mcollective fact called "node_roles":
node_roles: "compute ceph-osd"

Then we can execute shell cmd on all compute nodes like this:

mco rpc execute_shell_command execute cmd="/some_script.sh" -F
"node_role=/compute/"

Of course, we can use more complicated filters to run commands more
precisely.

[0]
https://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML
[1]
https://docs.puppetlabs.com/mcollective/reference/ui/filters.html#fact-filters
[2] https://docs.puppetlabs.com/mcollective/reference/plugins/facts.html


On Wed, Sep 10, 2014 at 6:04 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

> Hi folks,
>
> Some of you may know that there is ongoing work to achieve kindof
> data-driven orchestration
> for Fuel. If this is new to you, please get familiar with spec:
>
> https://review.openstack.org/#/c/113491/
>
> Knowing that running random command on nodes will be probably most usable
> type of
> orchestration extension, i want to discuss our solution for this problem.
>
> Plugin writer will need to do two things:
>
> 1. Provide custom task.yaml (i am using /etc/puppet/tasks, but this is
> completely configurable,
>     we just need to reach agreement)
>
>   /etc/puppet/tasks/echo/task.yaml
>
>   with next content:
>
>    type: exec
>    cmd: echo 1
>
> 2. Provide control plane with orchestration metadata
>
> /etc/fuel/tasks/echo_task.yaml
>
> controller:
>  -
>   task: echo
>   description: Simple echo for you
>   priority: 1000
> compute:
> -
>   task: echo
>   description: Simple echo for you
>   priority: 1000
>
> This is done in order to separate concerns of orchestration logic and
> tasks.
>
> From plugin writer perspective it is far more usable to provide exact
> command in orchestration metadata itself, like:
>
> /etc/fuel/tasks/echo_task.yaml
>
> controller:
>  -
>   task: echo
>   description: Simple echo for you
>   priority: 1000
>   cmd: echo 1
>   type: exec
>
> compute:
> -
>  task: echo
>   description: Simple echo for you
>   priority: 1000
>   cmd: echo 1
>   type: exec
>
> I would prefer to stick to the first, because there is benefits of using
> one interface between all tasks executors (puppet, exec, maybe chef), which
> will improve debuging and development process.
>
> So my question is first - good enough? Or second is essential type of
> plugin to support?
>
> If you want additional implementation details check:
> https://review.openstack.org/#/c/118311/
> https://review.openstack.org/#/c/113226/
>
>
>
>
> _______________________________________________
> 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/20140910/40ac6f8f/attachment.html>