Ansible stops executing on the host whenever it receives a non-zero return code from a command. We can handle these situations with the helps of settings and tools to behave as it we want.

Ignoring Errors Ansible stops executing commands on the host when it receives non-zero code, but we can ignore these errors and run the rest of the tasks as it is.

- name: I will cause an error
  ignore_errors: yes

Failed when Ansible let you define the condition when you want explicitly fail when a certain condition is true.

- name: Fail task under certain condition true
  command: ls/tmp/dir_not_exist
  register: result
  failed_when: result.rc == 0

Aborting on first error anyerrorsfatal finishes the fatal task on all hosts in the current batch, then stops executing on all hosts.

- hosts: somehosts
  any_errors_fatal: true
    - block:
         - include_tasks: sometask.yml

Handling errors with blocks Ansible let you control errors in a block with rescue and always section. In rescue, we can define tasks which we want to run when an earlier task in a block fails. You can also think of rescue as except and always as finally in other languages to handle errors.

- name: tasks to be run
     - name: task 1
       // code
     - name: task 2
       // code
     - name: task 3
       // code
     - name: Run when one of the above task fails
       // code
     - name: Always run 
       // code

Ansible provide ignore, rescue, always, failed_when to easily handle the behavior of playbook when we face any errors. We can use these commands/settings to gracefully record errors and take specific action.


#100DaysToOffload #Ansible

Ansible's tags are helpful to run a specific part of the playbook, rather running the whole playbook. Using tags, you can run or skip the tasks.

Tags can be added to one task or multiple tasks or role, block etc. Let see how to do that

Adding tags to a task

  - name: Assign the var
      name: apache2
      state: latest
      - vars
  - name: Enable and run httpd
      name: httpd
      state: started
      enabled: 'yes'
      - httpd
      - vars

Adding tags to role

  - role: config
      port: 8003
    tags: [ web, flask ]

Adding tags to block All the tasks in the block will share the same tag's

- name: git tasks
  tags: git
  - name: install apache
      name: git
      state: latest

Special tags Ansible have two special tags, never and always. If you add always tag to task, play, Ansible will always run the task or play, unless explicitly asked to skip with the help of (—skip-tags always)

On the other hand, never tag if assign to a task or play, Ansible will skip that task or play unless you explicitly asked it (—tags never).

Running the Playbook with tags

  • will run tasks with tag git : ansible-playbook example.yml --tags "git"

  • will not run tasks with tag git : ansible-playbook example.yml --skip-tags "git"

  • list all the tags : ansible-playbook example.yml --list-tags

  • run all tasks, ignore tags (default behavior): --tags all

  • run only tasks with either the tag tag1 or the tag tag2: --tags [tag1, tag2]

  • run all tasks, except those with either the tag tag3 or the tag tag4: --skip-tags [tag3, tag4]

  • run only tasks with at least one tag: --tags tagged

  • run only tasks with no tags: --tags untagged

That's all about the Ansible tags. Now go and tag your tasks :).


#100DaysToOffload #Ansible

While running your Ansible playbook, we can have the option of passing the argument from the command line. With the help of this, we define a generic playbook and use command line arguments to control the play. Let see how

Let's first start with the playbook, where we have defined the variable x is the playbook.

- hosts: all
    x: 45
    - debug: var=x

In this playbook, we will pass the value of x from the command line arguments with the help -e “value”.

- hosts: all
    - debug: var=x
>> ansible-playbook playbook_nmae.yml -e "x=56"

Now let's write a playbook which can uninstall/install a package with the help of command line arguments.

- name: Install/Unistall pacakges with command line
  hosts: all
  became: 'yes'
    - name: 'working with {{pkg}}'
        name: '{{pkg}}'
        state: '{{req_state}}'

Now, from the command line, we can pass the package name and state of the package.

>>ansible-playbook playbook_name.yml -e  "pkg=nginx req_state=present"

>>ansible-playbook playbook_name.yml -e  "pkg=nginx req_state=absent"


#100DaysToOffload #Ansible

Inventory(Hosts) file contains the information of the Ansible nodes. We can group based on our use case like web servers, DB servers and uses these groups to execute commands on them. But you have to create a group in the inventory file, let see how to do that.





You can even assign variable nodes or group wise in inventory file


IP_ADDRESS_1 ansible_user=myuser


#100DaysToOffload #Ansible #dgplug

Ansible Architecture

What is Ansible Ansible is a simple IT automation tool that make application and system easier to deploy and maintain. With the help of Ansible, you can automate task like network configuration, code deployment and cloud management. Ansible is an agent less system, which means that you don't need to install any software on the client system.

Inventory Inventory file is the one which contains the lists of the host servers on which Ansible works, it can be the IP Addresses, Domain name ...

Hosts It contains the IP addresses or Fully qualified domain name of the node servers which you want to configure.

Ansible.cfg This file contains the configuration for the Ansible, like the path of the Inventory file and values for the default variable in the Ansible

Ansible Nodes Ansible's nodes are the client system on which we want to execute, deploy or maintain the code(servers on which we want to work).

Ansible Engine Ansible engine/master/controller from which we manage all the server nodes.


#100DaysToOffload #Ansible #dgplug

Able to sneak out sometime today to watch this talk by Brain Chesky. Overall the talk is good worth spending your time on.

Brian Chesky on Launching Airbnb and the Challenges of Scale

My Notes

  • Find > What inside you have that no one else have
  • If you are not passionate about the thing you are doing, you will quit when the hard days come or thing go south
  • First best thing is to watch these all talks, but the second-best thing you can do is go out and build things by yourself.
  • Never wait to learn things before starting, just start and you will learn during the process.



I came to see this warning a few days back when I was seeing the git diff of a file in reaction to this I open the file and hit enter at the last line to my surprise the warning remains still the same.

What is a new line? The new line is usually \n, aka (CR or CRLF) at the end of the file. It's helpful to identify the last byte of the file.

Why it is good to have a new line at the end of the file?

Quoting from here

A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character. Since this is a “shall” clause, we must emit a diagnostic message for a violation of this rule.

So, it turns out that, according to POSIX, every text file should end with a \n, or “newline” (not “a new line”) character. This acts as the eol, or the “end of line” character. It is a line “terminator”.

It's helpful to identify the end of file.

How to automatically add one with your favorite editor?

In your favorite editor, you can add newline automatically like this.

  • Emacs : Add (setq require-final-newline t) to your .emacs or .emacs.d/init.el file.
  • VS Code: set “files.insertFinalNewline”: true

#100DaysToOffload #POSIX #Git #NoNewLine

It is an abstract machine that can be in exactly one of a finite number of states at any given time. A state machine is just a specification of how to handle events. It consists of a set of states, one of which is the current state. For each state, we list the events that are significant to that state. For each of those events, we define the new current state of the system.

Let see with an example

Stable (DB down) --> Critical (DB up) --> Stable (N/w down) --> Warning (N/w up) --> Stable


Here we have defined the states Stable, Critical, Warning and events DB down, DB up, and N/W down. In this case, we have a stable state so whenever our database goes down or the network goes down the state changes to critical/warning. We can link some logic with these states to perform any action for transition.

This logic can help in designing a good program around a problem statement that will have less coupled code and easy to maintain. Cheers!


Git is a version control tool, that helps to track changes in the project. We will discuss a few useful commands which are handy to know while working with the git

Creating a branch with no commits on it

>>> git checkout --orphan <branch_name>
>>> git log
fatal: your current branch '<branch_name>' does not have any commits yet

Remove stale branches In your local, if you have branches that are removed in the remote then you can use the prune command to delete those branches in local also.

>>> git remote prune origin

To pick a commit from another branch If you want to pick a commit from other branches into your current branch you can use the cherry-pick command and -x for when recording the commit, append a line that says “(cherry picked from commit ...)” to the original commit message to indicate which commit this change was cherry-picked from.

>>> git cherry-pick -x <commit SHA1>

To view commits that are not pushed yet

>>> git log @{u}..

Run previous command In Git, we are also switching from one branch to the other. Typing the name, again and again, is tedious. You can use - with the Git command, to save your self from typing the name again

>>>  randomos git:(useless_dict) git checkout add_numbers
Switched to branch 'add_numbers'
Your branch is up-to-date with 'origin/add_numbers'.
>>>  randomos git:(add_numbers) git checkout -
Switched to branch 'useless_dict'
Your branch is up-to-date with 'origin/useless_dict'.

If you have any Git commands which you feel are worth sharing and can save some time. Please do share.


#100DaysToOffload #Git #VersionControl

This Sunday, I attended the workshop on Creating Python modules using Rust by Kushal Das. The workshop started at 0900 UTC 18th April on Twitch.

The GitHub repo we follow along with the workshop can be found over here. Learned many new things in the workshop where we go through

  • Hello World example
  • User passed arguments
  • Exception Handling
  • File I/O
  • System Interaction (Process, System Information)

Enjoyed my time while going through these examples and like the way Kushal has arranged all the examples branch wise.


Useful Links –

#100DaysToOffload #Python #Rust