> > 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. 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. > > > 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. 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? 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. Including every line since last poll could stream several megabytes per host. Also then consider all of the modules that are API driven and don't have any intermediate status to provide, for which the apt module is *also* an example of this, as, are, for example EC2 modules. So, while trivially you could say "shell output since last run", that's a hack for just a small subset of the modules, which does nothing for package installs, cloud provisioning, fdisk, or many other things that would be much more benefitting of status than simple shell commands. The apt example, in particular, leverages python-apt in many cases, so it's very important to remember many of the APIs we are using are not written to provide asynchronous status. It's also important to realize that modules don't know when they are running in async mode - sure, it might be possible to augment the async system, but ultimately, it's a wrapper process that waits for a JSON response. 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. > > > 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/CA%2BnsWgxYC10f9uHuHe%2BmX5_NB1fTagzQ9-V2s6yqrXFhpx5aNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
