napalm-automation / napalm-ansible

Apache License 2.0
245 stars 103 forks source link

Introducing napalm_get_config module #131

Closed dmitryzykov closed 4 years ago

dmitryzykov commented 6 years ago

Introducing napalm_get_config module. This module will get configuration from a device with any OS supported by napalm and save it to a file in idempotent way.

Key arguments:

    dest:
        description:
            - File where to save a retrieved configuration from a device. Configuration won't be
              retrieved if not set.
        default: None
        required: True
    type:
        description:
            - Config type to retreive from device. If retrieved config is empty retrieve 
            "running" type instead.
        default: running
        required: False
        choices: ['running', 'candidate', 'startup']
    strip_comments:
        description:
            - Strip comments with timestamps from the config to behave in idempotent way. 
        default: False
        required: False

Examples:

- name: get the running config with stripped comments
  napalm_get_config:
    hostname: "{{ inventory_hostname }}"
    username: "{{ username }}"
    dev_os: "{{ os }}"
    password: "{{ password }}"
    dest: "../backup/{{ inventory_hostname }}"
    type: running
    strip_comments: True

- name: get the startup config using provider
  napalm_get_config:
    provider: "{{ ios_provider }}"
    dest: "../backup/{{ inventory_hostname }}"
    type: startup
dbarrosop commented 6 years ago

Hi, thanks for your contribution. What's the rationale to have a dedicated module instead of using napalm_get?

Regards David

dmitryzykov commented 6 years ago

Hi.

What's the rationale to have a dedicated module instead of using napalm_get?

I couldn't find napalm_get module. Do you mean get_facts or there is the napalm_get ansible module somewhere exists?

In our company, we have 1k+ devices and we want to scrape and backup configs from them by ansible. We found a napalm abstraction very useful for such tasks. But I couldn't find a way how to create device backups in an idempotent way using existing napalm ansible modules. So that I've written this module and shared it because it can be helpful for other.

We've successfully achieved our goal with napalm_get_config module and the following ansible role:

- name: create a backup path
  file:
    path: "{{ backup_path }}"
    state: directory

- name: backup config
  napalm_get_config:
    hostname: "{{ inventory_hostname }}"
    username: "{{ username }}"
    dev_os: "{{ os }}"
    password: "{{ password }}"
    dest: "{{ backup_path }}/{{ inventory_hostname }}"
    strip_comments: true
  register: config

- name: upload backup
  ... skipped uploading code ... 
  when: config.changed

This module supports optional comment's stripping with timestamps which allows achieving idempotency and with comparing previous backup and new backup we can provide proper changed status for this module.

ktbyers commented 6 years ago

@dmitryzykov Yes, the napalm_get_facts module. If you set the filter argument, you can call any NAPALM getter:

So something like:

- name: Get the device configuration
  napalm_get_facts:
    provider: "{{ device_provider }}"
    filter:
      - "config"
ktbyers commented 6 years ago

Some of the post processing items could still be valuable, however (i.e. strip comments, other items that are known to change).

dbarrosop commented 6 years ago

@ktbyers do you have any other comments/concerns we should address before merging?

dbarrosop commented 6 years ago

LGTM, @ktbyers you good?

bigHosting commented 4 years ago

My company has dozens of PA devices and we're using Ansible to backup cisco devices, so having the panos backup feature baked in would definitely help. Will this be merged ?

ktbyers commented 4 years ago

@bigHosting You can accomplish this very easily using the napalm_get_facts module. Given this hasn't been merged in almost 2 years and would potentially need to be re-written, I would probably look to use the napalm_get_facts module.

dmitryzykov commented 4 years ago

This PR hasn’t been merged for 2 years and it seems never will be merged. In that situation I’m not seeing any reasons to re-write it or keep that PR open.