Open Stack

Hi,

you described transport mechanism for running commands based on facts, we
have another one, which stores
all business logic in nailgun and only provides orchestrator with set of
tasks to execute. This is not a problem.

I am talking about API for plugin writer/developer. And how implement it to
be more "friendly"

On Wed, Sep 10, 2014 at 6:46 PM, Aleksandr Didenko <adidenko at mirantis.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/83d63cfd/attachment.html>