search

ansible-collections / cloud.common

Common files for the Cloud collections
GNU General Public License v3.0
16 stars 23 forks source link

How to best increase the daemon server ttl (override the 15s) #25

Open basselms opened 3 years ago

basselms commented 3 years ago
SUMMARY

Need the ability to override the default ttl for the daemon process to preserve the client session for specific period of time longer than the 15s default or until the playbook finishes executing. What's the best way to do that currently?

ISSUE TYPE
COMPONENT NAME

ansible_collections.cloud.common.plugins.module_utils.turbo.server ansible_collections.cloud.common.plugins.module_utils.turbo.module

ADDITIONAL INFORMATION

Can an implementation like this be supported?

class AnsibleTurboModule(ansible.module_utils.basic.AnsibleModule):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
       ...

      self.ttl = kwargs.get("ttl", 15)
EXAMPLE PLAYBOOK
        - name: "Establish config session and send commands to candidate mode"
          my_cutom_module_router_config:
            router_ip: "{{ r_ip] }}"
            username: "{{ r_user }}"
            password: "{{ r_pass }}"
            operations:
              - config
            config: "{{ cli_command_set }}"

        - Name: "Do other stuff..."
            pause:
            minutes: 15

        - name: "Must use previously created config session to commit config to running datastore"
          my_cutom_module_router_config:
            router_ip: "{{ r_ip] }}"
            username: "{{ r_user }}"
            password: "{{ r_pass }}"
            operations:
              - commit
            config: "{{ cli_command_set }}"
goneri commented 3 years ago

Some modules spend a lot of time just to prepare their execution environment (load SDK, open and auth a client, etc). The purpose of the ansible_module.turbo cache is speed up these modules. By design, the background service will kill itself after 15s. This means, after 15s without activity, next time a module tries to access the cache, it has to start a new background service. This task will be a bit slower, but this should not impact the playbook execution.

We can definitely define an environment variable to set a high duration.

Regarding your example, you use the background service like a database, I think this is risky. This cache has not been designed for that. I would suggest to use instead a cache on the filesystem or a DB.