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 <dshul...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
