Wouldn't the value change in the course of a play?
Michael DeHaan <mich...@ansible.com> napisał:
>Yeah that's an easy one, fortunately!
>
>That above thread that is well over a year and a half old, using some
>syntax in Ansible that is quite out of date, and legacy syntaxes like
>that
>have been pruned from Ansible in that time (after deprecating over the
>course of several releases with notes about how to upgrade)
>
>change the $PIPE(...) to:
>
>{{ lookup('pipe', 'date +%Y%m%d%H%M%S' }}
>
>Should be good to go!
>
>
>
>On Tue, Aug 26, 2014 at 5:58 AM, Sankalp Khare <sankalpkh...@gmail.com>
>wrote:
>
>> Doesn't seem to work for me:
>>
>> failed: [ec2-23-20-215-207.compute-1.amazonaws.com] => {"changed":
>true,
>> "cmd": "tar -cf $PIPE(date +%Y%m%d-%H%M%S).tar file1", "delta":
>> "0:00:00.007156", "end": "2014-08-26 08:46:56.146550", "rc": 2,
>"start":
>> "2014-08-26 08:46:56.139394", "warnings": ["Consider using unarchive
>module
>> rather than running tar"]}
>> stderr: /bin/sh: 1: Syntax error: "(" unexpected
>>
>> I've got this in the playbook :
>>
>> - name: Create timestamped backup
>> hosts: all
>> sudo: no
>> gather_facts: False
>> vars:
>> timestamp: $PIPE(date +%Y%m%d%H%M%S)
>> tasks:
>> - name: backup existing files
>> shell: tar -cf {{ timestamp }}.tar file1
>> args:
>> executable: /bin/bash
>> register: backup
>> ignore_errors: true
>>
>> Ansible is putting the verbatim contents of the timestamp var into
>the tar
>> command. I would've hoped those contents got evaluated first, into a
>> timestamp.
>>
>> Ps: why is the latest ansible checkout showing me cowsays instead of
>> regular play/task/... titles? :D
>>
>> e.g.
>>
>> __________________________________________________________
>> < PLAY [Upload new mobolt certificates and restart apache] >
>> ----------------------------------------------------------
>> \ ^__^
>> \ (oo)\_______
>> (__)\ )\/\
>> ||----w |
>> || ||
>>
>>
>> ____________________________________
>> < TASK: backup existing certificates >
>> ------------------------------------
>> \ ^__^
>> \ (oo)\_______
>> (__)\ )\/\
>> ||----w |
>> || ||
>>
>>
>> On Saturday, 23 March 2013 21:12:25 UTC+5:30, Michael DeHaan wrote:
>>
>>> I'm also not against making some more statistics based times
>available
>>> as magic variables, like $ansible_play_start_time or something like
>>> that.
>>>
>>> Patches would be considered.
>>>
>>>
>>>
>>> On Sat, Mar 23, 2013 at 11:41 AM, Michael DeHaan
>>> <mic...@ansibleworks.com> wrote:
>>> > BTW, the super easiest way to do this would be assigning the
>timestamp
>>> > in a bash wrapper script and then using
>>> >
>>> > --extra-vars="timestamp=foo"
>>> >
>>> >
>>> > On Sat, Mar 23, 2013 at 11:40 AM, Michael DeHaan
>>> > <mic...@ansibleworks.com> wrote:
>>> >> "Does this mean that it would be called twice per server in the
>>> >> example above and there would be the possiblity of different
>values
>>> >> for 'timestamp'?"
>>> >>
>>> >> Yes.
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Mar 22, 2013 at 3:50 PM, Clifford Sanders
><cliff...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Hi Michael,
>>> >>>
>>> >>>>
>>> >>>> You could into the $PIPE lookup plugin
>>> >>>>
>>> >>>> $PIPE(some command here)
>>> >>>
>>> >>>
>>> >>> so
>>> >>>
>>> >>> vars:
>>> >>> timestamp: $PIPE(date +%Y%m%d%H%M%S)
>>> >>> path_1: /app/releases/${timestamp}-v1.0/ROOT
>>> >>> path_2: /app/config/${timestamp}-v2.3.1
>>> >>> path_3: ${path_2}/properties
>>> >>>
>>> >>> would work? That would be great!
>>> >>>
>>> >>>>
>>> >>>> The only downside is it will be evaluated a *lot*, work to make
>this
>>> >>>> be evaluated outside of the multiprocessing loop can be done to
>make
>>> >>>> it convert to variables earlier, but I must say including a
>variable
>>> >>>> file based on the time and date seems
>>> >>>> a little complicated to me.
>>> >>>
>>> >>>
>>> >>> The documentation says:
>>> >>>
>>> >>> "... and if it is used in a variable definition, it will be
>executed
>>> each
>>> >>> time the variable is evaluated"
>>> >>>
>>> >>> Does this mean that it would be called twice per server in the
>>> example above
>>> >>> and there would be the possiblity of different values for
>>> 'timestamp'?
>>> >>> This would be ok for my use case I think. It is not essential
>that
>>> those
>>> >>> timestamps are equal.
>>> >>> I just need them to sort the folder names.
>>> >>>
>>> >>>> Can I ask what the underlying use case is?
>>> >>>
>>> >>>
>>> >>> Sure. I'm deploying using Ansible to deploy webapps and
>webservices
>>> to our
>>> >>> tomcat instances.
>>> >>>
>>> >>> The main steps of the workflow are:
>>> >>>
>>> >>> 1. download artifact (zip containing application war and
>>> configuration jar)
>>> >>> from Nexus into tmp folder /app/tmp and unpack
>>> >>> 2. unpack war to /app/releases/20130322201903-v1.0/ROOT
>>> >>> 3. create/change symlink /app/current_app to point to
>>> >>> /app/releases/20130322201903-v1.0
>>> >>> 4. unpack jar to /app/config/20130322201904-v2.3.1
>>> >>> 5. create/change symlink /app/current_config to
>>> >>> /app/config/20130322201904-v2.3.1
>>> >>> 4. delete /app/tmp
>>> >>> 5. restart tomcat
>>> >>>
>>> >>> In case of an error i would do a rollback by just changing the
>>> symlinks to
>>> >>> point to the folders to which they were linked before by reverse
>>> sorting the
>>> >>> folder names.
>>> >>> As I understand capistrano uses a similar mechanism like this to
>have
>>> a fast
>>> >>> and secure rollback.
>>> >>>
>>> >>> Maybe I'm getting it all wrong. So please feel free to make
>>> suggestions
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> Clifford
>>> >>>
>>> >>> Regards,
>>> >>>
>>> >>> --
>>> >>> 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 ansible-proje...@googlegroups.com.
>>> >>> For more options, visit
>https://groups.google.com/groups/opt_out.
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Michael DeHaan <mic...@ansibleworks.com>
>>> >> CTO, AnsibleWorks, Inc.
>>> >> http://www.ansibleworks.com/
>>> >
>>> >
>>> >
>>> > --
>>> > Michael DeHaan <mic...@ansibleworks.com>
>>> > CTO, AnsibleWorks, Inc.
>>> > http://www.ansibleworks.com/
>>>
>>>
>>>
>>> --
>>> Michael DeHaan <mic...@ansibleworks.com>
>>> CTO, AnsibleWorks, Inc.
>>> http://www.ansibleworks.com/
>>>
>> --
>> 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 ansible-project+unsubscr...@googlegroups.com.
>> To post to this group, send email to
>ansible-project@googlegroups.com.
>> To view this discussion on the web visit
>>
>https://groups.google.com/d/msgid/ansible-project/668848a9-cbfe-4865-a784-a00c6221de5d%40googlegroups.com
>>
><https://groups.google.com/d/msgid/ansible-project/668848a9-cbfe-4865-a784-a00c6221de5d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>--
>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 ansible-project+unsubscr...@googlegroups.com.
>To post to this group, send email to ansible-project@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxzd9YKoGU3H%2BS5CP1vnMWi4dW2QBaFQA9LRSFrRs%3Da4Q%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.
--
Wysłane za pomocą K-9 Mail.
--
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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/65e8cf5b-d6c6-475a-aa0a-c968955796c3%40email.android.com.
For more options, visit https://groups.google.com/d/optout.
