On Saturday, September 6, 2014 3:48:35 PM UTC+2, Michael DeHaan wrote:
>
> No, bringing it up periodically can't really help it make it be true any
> better.
>
Well I work professionally as a developer (like I am sure the vast majority
of the people on this list) and I can say the weight of user pressure
definitely changes our priorities at times.
> Please read my last comment I made in the ticket.
>
I did. Thanks for taking the time to respond about this. And sorry if my
responses seem persistent. I feel passionately about this point, and
unfortunately right now the response I am perceiving is "yep lots of people
want this, but we aren't / can't do anything about it... Please let this
go..." (But you have framed it in a very nice way :) ) So naturally I am
questioning around the edges of is there anything that can mitigate this to
at least some degree...
As for removing the +1's it sort of feels to me like I / we are loosing our
say in the community. It really wasn't that hard to scroll past a long list
of +1's, and in fact I was very very happy to see all the other +1's. it
made me as a user realise, "nope it's not just me, hey *everyone* else
really really wants this feature as well..." Ie the ansible community
really wants this, I should bring this up again...
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..."). (Hey... you guys have to make money somehow :) etc...) There are
all sorts of considerations I guess which I / we are not aware of but
still... it feels... well... I'll just say I liked seeing the plus ones...
Anyway, onto the actual points...
The most important point is point #1 -- nearly all of the modules involved
> have absolutely no API or notion of what percentage complete they are, but
> the other points are equally important.
>
1)
So just a query here: on the remote machine the python program that is
running, is it true that the running process fundamentally can't get the
output of command that is running until the end? For simplicity let's take
apt-get. As it runs it normally spits out information. Does the running
program on the host not have access to this information as it is being spit
out? Can't it for instance periodically store the current last line of this
output in a file somewhere? Then can't an async connection just query this
last line and write that out to the screen i.e..
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?
(Even better would be to only have a single line of output where the last
line is removed as soon as a new line is produced... so you see a single
line constantly being updated at the refresh frequency of the async poll...)
So I don't think each module actually needs to know what percentage
complete they are!
In general it is not even possible to know how long and arbitrary task is
going to take (some tasks like copying a file, transferring something, or
and apt task (which does have progress bars) would of course naturally have
this information available but at a first cut it wouldn't need to be
used...)
Of course adding it into the API so that future modules would be able to do
this would be a great step as well...
2) I don't understand why an sync task which would connect and basically
just be a "scp host /path/to/current/last/line/of/process/output" has to
have a server & crypto layer, etc. There is already an async process that
periodically sees if the task is finished.
3) I am suggesting this is basically just progress bars for async
connections. Ie the users writing the scripts decide when to do an async
operation, and they decide if the async process also grabs the last line of
output at the same time...
4) Well there would have to be some summarisation made of course but
something like the following print print multiple progress lines:
#!/usr/bin/env python
import sys
import time
import random
taskCount = 10
taskStrings = ["task "+str(i) +":" for i in range(taskCount)]
for i in range(20):
for ts in range(taskCount):
taskStrings[ts] += "." * random.randint(0,1)
print taskStrings[ts]
sys.stdout.write("\033[F"*taskCount) # Cursor up taskCount lines
time.sleep(0.3)
print ((" "* 30) + "\n") * taskCount
sys.stdout.write("\033[F"*(taskCount+1)) # Cursor up taskCount lines
5) Isn't this the exact performance characteristics of async. How does it
differ?
Again, sorry for the persistence. This is a feature that I think would make
ansible much better...
Thanks, for your consideration.
Jason
For completeness in my thread, here's my full reply to that ticket:
>
> Hi everyone,
>
> I've closed this ticket as I think many people understand what is going on
> here and why we have acted on it.
>
> These reasons have been enumerated previously and include:
>
> *1) Ansible contains 235+ modules and the APIs used in basically all of
> these modules don't have any capacity for reporting status in the middle of
> an async operation*
>
> 2) To do this properly for N-node management it implies setting up a
> server and a crypto layer that eliminates much of the architectural
> elegance of ansible
>
> 3) If you just need to know if a module is still running, async is
> available -http://docs.ansible.com/playbooks_async.html
>
> 4) The CLI has no good way to output standard out changes when running in
> parallel against several hundred hosts
>
> 5) The performance implications of doing this over an additional SSH
> channel or other mechanism are decidedly non-trivial
>
> It's not that we are denying anyone this out of spite, it's actually not a
> good fit for the system.
>
> We strongly encourage usage of async to show long running tasks are alive.
> Consider having custom modules, if any, log their actions, to diagnose
> problems should they occur.
>
> Ansible does in fact report in when each host comes back in a large set of
> hosts, so that progress is definitely available.
>
> Thanks for your understanding.
>
> So that comments are easy to read I am also removing the various (and
> numerous) +1s on this file. I appreciate the feedback, but voting cannot
> make it so.
>
>
--
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/b65fbb9d-236e-4b9e-b4dc-dfcb27784c83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
