Open Stack

Dmitry,
thanks for sharing CLI options. I'd like to clarify a few things.

> 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.

>>> 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

> 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]

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.

> Also we are working on deployment graph visualization
yes, this would be awesome to have. When I specify --start and --end, I'll
want to know what is going to be executed in reality, before it gets
executed. So something like dry-run which shows execution graph would be
very helpful.

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.
   2. 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?
   3. 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)

Thanks Dmitry!

On Sat, Feb 7, 2015 at 12:16 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

>
> Thank you for the excellent run-down of the CLI commands. I assume this
>> will make its way into the developer documentation? I would like to know if
>> you could point me to more information about the inner workings of granular
>> deployment. Currently it's challenging to debug issues related to granular
>> deployment.
>>
>
> All tasks that are in scope of role are serialized right into deployment
> configuration that is consumed by astute. So it can be traced in the logs
> (nailgun or astute) or in astute.yaml that is stored on node itself. Here
> is what it looks like [0].
> Some other internals described in spec -
> https://review.openstack.org/#/c/113491/.
>
> For developer it makes sense to get familiar with networkx data structures
> [1], and then dive into debuging of [2].
> But it is not an option for a day-to-day usage, and UX will be improved by
> graph visualizer [3].
>
> One more option that can improve understanding is human-readable planner..
> For example it can output smth like this:
>
> >> fuel deployment plan --start hiera --end netconfig
>
>    Manifest hiera.pp will be executed on nodes [1,2,3]
>    Manifest netconfig will be executed on nodes [1,2]
>
> But i am not sure is this thing really necessary, dependencies are trivial
> in comparison to puppet, and i hope it will take very little time to
> understand how things are working :)
>
> As an example there is a bug [0] where tasks appear to be run in the wrong
>> order based on which combination of roles exist in the environment.
>> However, it's not clear how to determine what decides which tasks to run
>> and when (is it astute, fuel-library, etc.), where the data comes from.
>> etc.
>>
>
> As for the bug - it may be a duplicate for
> https://launchpad.net/bugs/1417579, which was fixed by
> https://review.openstack.org/#/c/152511/
>
> [0] http://paste.openstack.org/show/168298/
> [1]
> http://networkx.github.io/documentation/latest/tutorial/tutorial.html#directed-graphs
> [2]
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_graph.py#L29
> [3] https://review.openstack.org/#/c/152434/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150207/035c9f29/attachment.html>