Open Stack

On Fri, Feb 6, 2015 at 11:16 PM, Mike Scherbakov <mscherbakov at mirantis.com>
wrote:

> 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.
>
> The way I've seen this work so far is the missing role in the graph simply
wont be executed, not the requested role


> >>> 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
>
> provision and deploy tasks are already under node so it makes some sense
to keep them here unless everything moves


> > 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]
>
this already appears to work as
fuel node --node 1,2,3 --task netconfig compute

>
>
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.
>
We need to start with a better graph of everything that will run on each
node and in which order, I've yet to see something that renders the whole
graph including the requested deps on each node. It will be very useful for
debugging.


> 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.
>
> The puppet based tasks run and should show errors the same as legacy
deployments or plugin tasks

>
>    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?
>
> fuel node --node 1 --tasks netconfig

>
>    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)
>
> that's exactly how it works


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


-- 
Andrew
Mirantis
Fuel community ambassador
Ceph community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150206/de439e18/attachment.html>