What do you think of adding time-related vars in the ansible facts?
For example, it would be convenient if someone could use $ansible_date
as suffix/prefix of a backup file in a 'backup' action.
It should not be done at fact level as the dates would be different per host.
Rather, it sounds like there should be a playbook level variable "time" that gets reset before each task is run, and that gets shoved somehow
into the template dictionary data.
I do find this useful though, because you could easily do things like
# templates by Ansible on {{ time }}
at the top of the file.
So yes to this, but not with facts.
On the other hand, you may actually want exactly that behavior. For
example, if you take a backup at the same time on different hosts that
are in different timezones, it would make more sense to have appended to
the backup files the local times of each host, so that local
administrators know exactly how old their backups are and not be
surprised with, let's say, backups that seem to have been taken in the
future (although, Le Guin's ansible could perhaps do that :P).
ok, I'll accept local_time as a fact, but would want:
local_epoch_time -- seconds since 1970
local_time -- whatever ASCII format, must include the timezone offset
we can leave the other for later.
Could we just make this more generic and allow the results of a command to be assigned to a var for a future command?
Also, it would be useful to have the idea of running a one-off task on the host running a playbook vs the task running on every target
So for something where date is always the same:
action: command local=true resultvar=singledate date +%Y%m%d-%H%M%S
And where you want local time or different times
action: command resultvar=systemdate date +%Y%m%d-%H%M%S
And then use $singledate or $systemdate in later tasks.
I’m sure none of the above is simple, just an idea for a different mechanism that is more widely applicable.
Could we just make this more generic and allow the results of a command to
be assigned to a var for a future command?
Returning the time in the setup data is useful because it wouldn't
require an extra hop.
That being said, the "store result in variable thing" will come in 0.7.
Also, it would be useful to have the idea of running a one-off task on the
host running a playbook vs the task running on every target
We're talking about 3 things in one email now, but the idea of running
something on the localhost with info about the remote hosts is
something that will be coming.
action: command local=true resultvar=singledate date +%Y%m%d-%H%M%S
It would be more like this:
action: foo
local_action: True # I need a much better word for this
not to be confused with connection: local
the variable storage stuff is also seperate and would be more like:
action: command date
store_as: date
again, this is about 4 separate things now 