On Sunday, September 7, 2014 5:22:49 AM UTC+2, Michael DeHaan wrote: > > > Of course it is your prerogative, and there are development schedules and >> all sorts of things to consider, and maybe this clashes with your >> commercial offering (i.e. from the press release: "Tower's real-time >> output of Ansible Playbooks includes dynamic progress bars that show you >> the status of jobs and hosts, along with the overall status of the Playbook >> run..."). >> > > Please don't accuse us of holding back from ansible, this has never been > the case. > Ok.
> Tower's feature is the playbook output streams in via websockets *just > like it does from /usr/bin/ansible-playbook* so you don't have to hit "F5" > to reload the page. > > That's it. CLI equivalence. > > In some ways it provides some cleaner ways to dive through the final > output, because a web interface is superior for some of these kinds of > searches, but it is using clean-stock-ansible underneath, without > modifications. > > The progress bar you get is the number of hosts having checked in yet, not > the intermediate status of invididual hosts. Which in reply to Adam > above, we've indicated we'd be totally happy to see in the CLI output too. > > Yes, it's formatted differently. Do modules return different information > in Tower or does Tower have proprietary modules? Absolutely not. > > It doesn't have anything to do with intermediate status from modules. > Right in my original email this was a progress bar at the top level. I was thinking a playbook has something like 50 plays in it, I would like to see a progress bar of 1 through 50 multiplied by the number of hosts... > instead of the async task producing: >> >> <job 409801362883.2948> polling, 990s remaining >> <job 409801362883.2948> polling, 980s remaining >> <job 409801362883.2948> polling, 970s remaining >> <job 409801362883.2948> polling, 960s remaining >> <job 409801362883.2948> polling, 950s remaining >> >> There could be an option so it prints: >> >> <job 409801362883.2948> polling, 980s remaining, current: (Reading >> database ... 84711 files and directories currently installed.) >> <job 409801362883.2948> polling, 970s remaining, current: Selecting >> previously unselected package libmono-2.0-dev. >> <job 409801362883.2948> polling, 960s remaining, current: Selecting >> previously unselected package libmono-system-xml4.0-cil. >> <job 409801362883.2948> polling, 950s remaining, current: N: Ignoring >> file 'opera.list.save' in directory '/etc/apt/sources.list.d/' as it has an >> invalid filename extension >> <job 409801362883.2948> polling, 940s remaining, current: Reading state >> information... Done >> > > etc. Is this not possible? >> > > Doesn't really matter, it's also not what you want. You think it is, but > it's not. > No. It really is what I want. I want it so that it prints a single line and then it overwrites that *same* line at the next poll. I would then likely set the poll frequency fairly low so I could see if the process is hung. Eg if you look at e.g. some virus checkers, they print the file they are checking. These files fly by so fast you can't even really read them. But if it ever stops then you know the thing is hung up a bit. That is the principal I am talking about here... Imagine you have 500 hosts. Do you want just the last line at every poll > attempt? What if you want the log runs? What if you wanted the last 10 > lines? What's the right behavior in every single module to do this? Do > you want to interleave output from all 500 hosts? > You could make it a parameter if you are really interested. But a single line which is constantly overwritten would give the user enough feedback... > The last line of output at the moment you poll is a poor solution, and is > subject to some relatively bad sampling problems, that will almost always > miss the information you want. > It is not meant to be a log. It is meant to tell you if the process is still going... > ... > So what you ask isn't trivial by any means - to present, to retrofit the > modules, to retrofit async, etc. > > The shell module appears to be the easy case, but it exposes it's own > manner of complexity. > > Progress bars are 100% right out. > Well... that is unfortunate, it is a feature many people clearly want... Ohh well... Thanks for answering the emails. Cheers, Jason > > >> >> >> Again, sorry for the persistence. This is a feature that I think would >> make ansible much better... >> >> > Many things would make ansible much better. > > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/6e7bcf1d-480f-41cc-b9cb-9f93c77d7520%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
