Ansible Remote Versioning

[Firesh Bakhda]

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  ?

[Jean-Yves LENHOF]

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

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/977f9bab-9572-40e2-a122-cbbc5295b830o%40googlegroups.com.

[Firesh Bakhda]

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 ? 

[Jean-Yves LENHOF]

Hi,

I gave you some ideas, I did'nt say this is a good practice to know what tasks has been already ran.

When you produce ansible role and playbook, you should ensure that you can run it whenever previous state was and if run more than once without modification results on server should be the same !

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5737250d-e71e-406a-a1e2-aba8a1996079n%40googlegroups.com.

[Stefan Hornburg (Racke)]

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 jyle...@gmail.com 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 ansible-proje...@googlegroups.com.
>> 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

> ansible-proje...@googlegroups.com <mailto:ansible-proje...@googlegroups.com>.

> 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.

[Phil Griffiths]

Hi Firesh

You are in danger of re-inventing the wheel here.

As Jean-Yves points out, you are starting to negate the whole point of Ansibles idempotency. You write something once and no matter how many times you run it, it checks and only makes changes as necessary. Writing a timestamp to every file on every remote host is not a good practice.

So you want to log what's going on? As Stefan points out look at something like ARA or better still look at AWX was you'll probably quickly get to the point of needing other features which AWX has taken care of.

Regards

Phil.

[Brian Coca]

Ansible also uses the target's log facility (syslog or journal) to
leave a log of the actions performed.

--
----------
Brian Coca