On 7/22/20 9:36 AM, Firesh Bakhda wrote:
> Hi JYL,
> 
> This is a great insight you have provided. That would certainly a good way on 
> how to manipulate the Ansible and Ansible
> Tasks on each runs. 
> What what it doesn't solve is that how do i populate that fact file with 
> Tasks that has already been ran. 
> 
> For example,  at the end of each Ansible run, if i could generate a JSON file 
> that would look like: 
> 
> {
>     "Task1":1,
>     "Task2":1
> }
> 
> And on Ansible, I can write "When: {{ ansible_local["Task1"] }} exists and {{ 
> ansible_local["Task1"] }} == 1"
> then skip the task. This is ideal.
> 
> However, to generate the fact.d JSON file, i need a way for to know what 
> tasks have been executed in the first place, 
> and thats something i am figuring out, how can i know within this ansible 
> run, what were the tasks executed ? 
>     

Hello Firesh,

maybe ARA (https://ara.recordsansible.org/) can help you here.

Regards
         Racke

> 
> 
> 
> On Tuesday, July 21, 2020 at 3:03:28 PM UTC+8 [email protected] wrote:
> 
>     Interesting question.
> 
>     A local fact is a way :
> 
>     
> https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#local-facts-facts-d
> 
>     At the beginning of your playbook you test is the fact relating to your 
> playbook exist.
> 
>     If existing, is the version different from the playbook you use
> 
>     Do things differently if the version is x or y
> 
> 
>     Generally, this could be avoided using some automated test to not make 
> regression in a future version (molecule
>     could be useful here if target is a server)
> 
>     Regards,
> 
>     JYL
>     ||
> 
> 
>     Le 21/07/2020 à 08:08, Firesh Bakhda a écrit :
>>     Hi ,
>>
>>     I would like to post to this group to find out if there is anyway for 
>> ansible to actually stamp the client with 
>>     Ansible Deployment or Deployment Stamp on what tasks were ran and when 
>> it was ran, like a VERSION or DEPLOYMENT
>>     file that we could deposit to the targets. 
>>
>>     For example, 
>>
>>         On first deployment the ansible scripts may just have tasks like: 
>>
>>          1. APT UPDATE
>>          2. NTPDATE
>>
>>         this then was deployment and stamps on the client like this: 
>>
>>          1. Ansible Deployment 21/07/2020 13.35pm - v1.0
>>              1. Tasks:
>>                  1. APT UPDATE 21/072020 13;40pm 
>>                  2. NTPDATE 21/072020 13.42pm
>>
>>
>>         Then this ansible script was updated to contain 2 more tasks like 
>> the below:
>>
>>          1. APT UPDATE
>>          2. TIMESYNC DAEMON UPDATE
>>          3. NTPDATE
>>          4. PROXY UPDATE
>>
>>         And when this was ran again, the target system file gets updated 
>> once it completes with:
>>
>>          1. Ansible Deployment 21/07/2020 13.35pm - v1.0
>>              1. Tasks:
>>                  1. APT UPDATE 21/072020 13;40pm 
>>                  2. NTPDATE 21/072020 13.42pm
>>          2. Ansible Deployment 21/07/2020 14.00pm - v1.1
>>              1. Tasks:
>>                  1. APT UPDATE 21/07/2020 14.01pm
>>                  2. TIMESYNC DAEMON UPDATE 21/07/2020 14.03pm
>>                  3. NTPDATE 21/07/2020 14.04pm
>>                  4. PROXY UPDATE 21/07/2020 14.07pm
>>
>>
>>
>>     Something like this, this allows those who are maintaining individual 
>> platforms gets to know if the deployed
>>     platform is upto date or not. 
>>     This would also help to know if the target system is to the latest 
>> deployment or not. 
>>     Or is there any mechanism for this  ?
>>
>>
>>
>>     -- 
>>     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 view this discussion on the web visit
>>     
>> https://groups.google.com/d/msgid/ansible-project/977f9bab-9572-40e2-a122-cbbc5295b830o%40googlegroups.com
>>     
>> <https://groups.google.com/d/msgid/ansible-project/977f9bab-9572-40e2-a122-cbbc5295b830o%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 
> -- 
> 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] 
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/5737250d-e71e-406a-a1e2-aba8a1996079n%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/5737250d-e71e-406a-a1e2-aba8a1996079n%40googlegroups.com?utm_medium=email&utm_source=footer>.


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/631d21c3-9f48-50cb-bd65-ebb5691c2b24%40linuxia.de.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to