Let's not create architectural leaks here. Let there be only tasks, but
let's create a really simple template for task that user will be able to
easily fill only with the command itself.
On Thu, Sep 11, 2014 at 4:17 PM, Evgeniy L wrote:
> Hi,
>
> In most cases for plugin developers or fuel users
Hi,
In most cases for plugin developers or fuel users it will be much
easier to just write command which he wants to run on nodes
instead of describing some abstract task which doesn't have
any additional information/logic and looks like unnecessary complexity.
But for complicated cases user will
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 t
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]
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
orchest
