refactor(libsaltcli): use libsaltcli library to improve readability

[myii]

PR progress checklist (to be filled in by reviewers)

• Changes to documentation are appropriate (or tick if not required)
• Changes to tests are appropriate (or tick if not required)
• Reviews completed

---

What type of PR is this?

Primary type

• [build] Changes related to the build system
• [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
• [ci] Changes to the continuous integration configuration
• [feat] A new feature
• [fix] A bug fix
• [perf] A code change that improves performance
• [refactor] A code change that neither fixes a bug nor adds a feature
• [revert] A change used to revert a previous commit
• [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

• [docs] Documentation changes
• [test] Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.

Related issues and/or pull requests

• Based on chore(libsaltcli): add lib to check type of Salt command being used template-formula#131

Describe the changes you're proposing

@baby-gnu I've tested this out with salt-ssh and it appears to be working fine. It takes away some of the complexity from map.jinja and it also allows us to use this library anywhere else we need it.

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

• Updated the README (e.g. Available states).
• Updated pillar.example.

Testing checklist

• Included in Kitchen (i.e. under state_top).
• Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
• Updated the relevant test pillar.

Additional context

[myii]

If this works out, I'll update the PR in the template-formula, so that it can be considered for merging.

[myii]

It would be simple to manage libsaltcli.jinja from the ssf-formula as well, since it's static, like libtofs.jinja.

[baby-gnu]

This clarify map.jinja.

Thanks.

[baby-gnu]

Sorry for not using it I was falsely convinced that import and include was not working in map.jinja but it's only in templates managed by file.managed

[saltstack-formulas-travis]

🎉 This PR is included in version 3.7.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[myii]

@baby-gnu I found out that there is an #ssh channel in Slack so I asked a question there about the method we're using. This was the reply:

15:15 Imran Iqbal
Would it be correct to assume that a salt-ssh call can be identified using the following? https://github.com/saltstack-formulas/libvirt-formula/pull/71/files#diff-cce566026d2f88ea83eb2334df577824R7-R9
15:15

{%- elif salt['config.get']('__cli') == 'salt-call' %}
{%-   if salt['config.get']('root_dir').endswith('/running_data') %}
{%-     set cli = 'ssh' %}

15:16 Imran Iqbal
Mainly asking about that second line. Will root_dir always end with '/running_data'?

06:30 Max Arnold
What about the following expression (I believe I posted it earlier)?

{% if opts.get('__master_opts__', {}).get('__cli')) == 'salt-ssh' %}

12:58 Imran Iqbal
@​marnold Yes, that works specifically for salt-ssh, so that's worth using as a test, thanks. opts.get('__master_opts__', {}).get('__cli')) evaluates to None for minion or local calls, so we could stick with the same conditionals for those.

So I reckon we should change the test on this line accordingly:

libvirt-formula/libvirt/libsaltcli.jinja

Line 8 in 2d557f2

{%- if salt['config.get']('root_dir').endswith('/running_data') %}

Would you like to test it at your end first?

-{%-   if salt['config.get']('root_dir').endswith('/running_data') %}
+{%-   if opts.get('__master_opts__', {}).get('__cli')) == 'salt-ssh' %}

---

Looking at the docs, I've also found that we can use config.get.

https://docs.saltstack.com/en/latest/ref/states/vars.html#opts

The config.get function also searches for values in the opts dictionary.

So we could use the following instead:

-{%-   if salt['config.get']('root_dir').endswith('/running_data') %}
+{%-   if salt['config.get']('__master_opts__', {}).get('__cli')) == 'salt-ssh' %}

Not sure if there's any benefit to doing that, though.

[baby-gnu]

Thanks @myii for the feedback, it works fine.

Both choices require internal implementation knowledge but the second is more explicit about salt-ssh.

So libsaltcli.jinja would looks like this

# -*- coding: utf-8 -*-
# vim: ft=jinja

{#- Determine the type of command being run #}
{%- if salt['config.get']('__cli') == 'salt-minion' %}
{%-   set cli = 'minion' %}
{%- elif salt['config.get']('__master_opts__', {}).get('__cli') == 'salt-ssh' %}
{%-     set cli = 'ssh' %}
{%- elif salt['config.get']('__cli') == 'salt-call' %}
{%-    set cli = 'local' %}
{%- else %}
{%-   set cli = 'unknown' %}
{%- endif %}
{%- do salt['log.debug']('[libsaltcli] the salt command type has been identified to be: ' ~ cli) %}

Which could be optimized.