Open Stack

> > Also very important to understand that if task is mapped to role
> controller, but node where you want to apply that task doesn't have this
> role - it wont be executed.
> Is there a particular reason why we want to restrict a user to run an
> arbitrary task on a server, even if server doesn't have a role assigned? I
> think we should be flexible here - if I'm hacking something, I'd like to
> run arbitrary things.
>

The reason it is not supported is that such behaviour will require two
different endpoints, with quite similar functionality.
In most cases developer will benefit from relying on role mappings, for
instance right now one will be able to test dependent tasks on
different nodes by next commands:
>> fuel node --node 1,2,3 --tasks corosync_primary corosync_slave
>> fuel node --node 1,2 --tasks controller_service compute_service
IMO it is reasonable requirement for developer to ensure that task is
properly inserted into deployment configuration.

Also there was a discussion to implement an api that will bypass all
nailgun logic and will allow to communicate directly with orchestrator
hooks, like:

>> fuel exec < file_with_tasks.yaml

Where file_with_tasks filled with data consumable directly by orchestrator


> >>> fuel node --node 1,2,3 --end netconfig
> I would replace --end -> --end-on, in order to show that task specified
> will run as well (to avoid ambiguity)
>
> This is separate question probably about CLI UX, but still - are we Ok
> with missing an action verb, like "deploy"? So it might be better to have,
> in my opinion:
> fuel deploy --node 1,2,3 --end netconfig
>

We may want to put everything that is related to deployment under one CLI
namespace, but IMO we need to be consistent and regular deploy/provision
should be migrated as well. '

> For example if one want to execute only netconfig successors:
> >>> fuel node --node 1,2,3 --start netconfig --skip netconfig
> I would come up with shortcut for one task. To me, it would be way better
> to specify comma-separated tasks:
> >> fuel deploy --node 1,2,3 --task netconfig[,task2]
>

I dont like comma-separted notation at all, if majority will think that it
is more readable than whitespace - lets do it.

Question here: if netconfig depends on other tasks, will those be executed
> prior to netconfig? I want both options, execute with prior deps, and
> execute just one particular task.
>

When tasks provided with --tasks flag - no additional dependencies will be
included. Traversal will be performed only with --end and --start flags.


> As a separate note here, a few question:
>
>    1. If particular task fails to execute for some reason, what is the
>    error handling? Will I be able to see puppet/deployment tool exception
>    right in the same console, or should I check out some logs? We need to have
>    perfect UX for errors. Those who will be using CLI to run particular tasks,
>    will be dealing with errors for >95% of their time.
>
> There will be UI message that something with that id is failed. But
developer will need to go for logs (astute preferably).
What you are suggesting is doable, but not that trivial.. We will check how
much time this will take, and maybe there is other ways to improve
deployment feedback.

>
>    1. I'd love to have some guidance on slave node as well. For instance,
>    I want to run just netconfig on slave node. How can I do it?
>
> You mean completely bypassing fuel control plane? Developer will be able
to use underlying tools directly, puppet apply, python, ruby, whatever
that task is using.
We may add a helper, to show all tasks endpoints in single place, but they
can be found easily by usual grep..

>
>    1. If I stuck with error in task execution, which is in puppet. Can I
>    modify puppet module on master node, and re-run the task? (assuming that
>    updated module will be rsynced to slaves under deployment first)
>
> Rsync puppet is separate task, so one will need to execute:

>> fuel node --node 1,2,3 --tasks rsync_core_puppet netconfig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150207/8c91c0c7/attachment.html>