Logic analog to Ansible (register output)

[Johann Kappacher]

Hello

after evaluating Ansible, I try to start with Salt ... and I also try to find common procedures in use ...

For example:

In Ansible, "tasks in a play" perform like a sequence of execution module functions in an orchestrate runner.

(or - sometimes - state module functions in a state file?)

At the end of each task, I can (optionally) assign the output of the module function (a return structure in json formatted to python dict)

to a - so called - register variable.

During the next tasks till the end of a play (mostly the end of file), I can use the values/strings found in this register variable as a conditional - or list in a loop - for the next steps.

Question:

How do you form a equivalent state/orchestration (combined with jinja?) that plays in such a way?

(Output of task X ist stored to variable x1 and is used as a conditional or input for task Y...)

Because this is the way I am challenged with questions like "Why Salt over Puppet or Chef or Ansible ...?".

Thanks to any hints or suggestions

Hannes (a nickname for John/Johann)

[David Boucha]

I don't think Salt has the exact same concept of a register variable like in Ansible, but Salt does have a rich set of "requisites" that allow you to

create dependencies and even branch based on failures. The main docs are here: https://docs.saltstack.com/en/latest/ref/states/requisites.html

Do you have an example I could look at?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ryan Lane]

Salt doesn't have a 1:1 equivalent of Ansible's registers because there's a fundamental difference in how Ansible and Salt work with regards to Jinja rendering. Salt has a rendering pipeline, which by default is Jinja -> Yaml -> in memory states. Ansible is Yaml -> Plays -> Jinja. When a play runs, it stores a play's output in registers that can be used in the Jinja of later plays. This is because Ansible renders the Jinja in the play, rather than before the playbook is generated.

Salt _does_ have some functionality like this, via __context__ and aggregates, but it's not really very end-user accessible. For the most part it's up to authors of execution and state modules to have them integrate with each other in ways that make sense.

A good example of how this works in Salt is some of the various boto_* state modules. The boto_elb state module integrated with the boto_route53 state module to automatically link load balancers with DNS:

```yaml
Ensure myelb elb exists:
  boto_elb.present:
    - name: myelb
    - subnets:
        - subnet-12345
        - subnet-12346
        - subnet-12347
    - scheme: internal
    - security_groups:
        - mysecgroup
    - listeners:
        - elb_port: 80
          instance_port: 80
          elb_protocol: HTTP
          instance_protocol: HTTP
    - cnames:
        - name: myservice.example.com.
          zone: example.com.
```

In the above, salt will ensure an ELB is created, and it'll take the output from the ELB info and will use it to make a CNAME entry in route53 that points myservice.example.com to the maintained ELB.

In Ansible the analog is to run an ELB play, take its output and feed that into the route53 play's Jinja.

Both approaches have their merits. Ansible is a bit more flexible because you can take random outputs and use them as inputs to anything you want. Salt's approach is more integrated and makes it way easier to write states that make sense as single states, rather than chaining a bunch of code together.

- Ryan

[Johann Kappacher]

Thanks for the clarification!

I see, the Jinja rendering works completely different in Ansible/Salt.

I will try to find a salt approach for my salt states ...

[sfresher]

So in another words, Salt has not way to do chained states call like Ansible, and we have to write our own states to glue them together?

[Florian Ermisch]

Hi sfresher, Hannes,

if your "chained states" get beyond the scope of simple state
files you should use the orchestrate runner. If you do so you
can just query the results of the previously run state inside
the next state's jinja. A little cleaner approach would be
storing the results in grains or the salt mine and query those.
There are rarely cases you need random return values like
UUIDs on the operator side of things as you should have human
readable identifiers - even if they are worse then "web-la-26",
"web-sf-5" and "db-ny-7". You should be able to look up those
mappings and if you can't you should rethink your approach to
orchestration/designing your infrastructure ;)
And of course, a state module should be able to figure out
which UUID to send to $PROVIDER's API to address your instance
called "appserver-singapore-17" and return an error if the
name matches multiple instances.

hth, Florian

[sfresher]

Thank you for detailed reply.  However, I am looking at Salt orchestrate runner doc https://docs.saltstack.com/en/latest/topics/orchestrate/orchestrate_runner.html#orchestrate-runner, but still couldn't figure out how can I query the results of the previous run state?

[Alex Leonhardt]

Not sure if this video will help you achieve what you need / want ?

It's by Ryan Lyft about orchestrating AWS with Salt - https://youtu.be/94TSWxyapuU

[Johann Kappacher]

Hello

thanks for the replies!

But now we come to the striking point:

How to store state results without having to customize or create state modules?

There is no directive like Ansible's "register:" to store the state results.

(Hmm, but I could hack the state.sls or state.orch to provide interim results?)

For instance, mod_aggregate works for state modules that support this feature, only.

And "__context__" / context dict is not accessible in the SLS file.

[Robert Chen]

anyone has a solution for this? This is too bad, everything we need to write a state module. 

[Jeremy McMillan]

This is a wrong approach to evaluating "Why Salt over Puppet or Chef or Ansible".

Tell us what your high level use case is: the story. When we have your story, we can help you understand how salt can accomplish this goal.

You are forgetting to first answer "HOW Salt and HOW Puppet and HOW Ansible." Understanding how is a prerequisite for understanding why.

Salt is an event based orchestration tool. In salt, we might think your second step must react to the first step. You need to provide a "getter" custom execution module function which returns the boolean conditional or iterable values. Then you can make the first step "mine" (advertise, or "register") the values, effectively using the salt mine as you would the Ansible register variable. The second step might use the salt mine in jinja to conditionally or iteratively describe your desired second step states. To chain the steps together, either run the second state.apply using a reactor defined to trigger on the mine update, or define the first and second steps with requisites in an orchestration.sls.

With salt, this approach will allow the first step to trigger any number of (elastically scaled?) second steps on different (potentially very many highly distributed) minions: for example your first step might add some API functionality, and the second step might set up a whole layer of web proxies to provide the functionality through a new REST endpoint on a particular URL path. I'm guessing wildly at your use case. I hope this sheds some light on how you might use salt.

[Mircea Ulinic]

In addition to what Jeremy already pointed out, I would also mention: remember that inside any SLS file (be it Pillar or State SLS etc.) you can invoke any execution function you may need, e.g., while on the CLI you execute

$ salt-call test.ping

, inside SLS you can do:

{%- set res = salt.test.ping() %}

It is very powerful, and I'm not aware of any way to achieve the same (or anything comparable) with other existing tools.

This is applicable to any of the available execution functions: https://docs.saltstack.com/en/latest/ref/modules/all/index.html - including those from state execution module, e.g., if you want to get the output of a state you'd simply have:

{%- set res = salt.state.apply('some-state-sls') %}

Then manipulate the variable res and do the business logic you need based on the state output.

Using this simple rule (in different ways), I couldn't find yet any corner case I couldn't resolve.

Does this answer your question?

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/22e5e212-cdaa-459e-a006-74b74fa4ad74%40googlegroups.com.

[Johann Kappacher]

Thanks,

I guess this could work ...

Now, I am going to find and test several use cases for my company, I will give you feedback asap. 

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.

[Daniel Wallace]

If you need to get information about the system at runtime, instead of compile time, you can use the new __slots__ feature in 2018.3.0

https://docs.saltstack.com/en/latest/topics/slots/index.html

You can use any module available, or write a custom one to do the verifying work that you need.

Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/e8cde75b-1a0d-4f2a-8a61-c97371565047%40googlegroups.com.

[Johann Kappacher]

Wow, thanks for the hint, this is the right direction!

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/fotHcqUvzOc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CAA2%2B9hD5kNvs1FBcHfxzEnTprrfnh5eSy_j-s6-p3%2BijPFptqQ%40mail.gmail.com.

[Rémy Dernat]

Hi,

I have done something similar before existence of slots or even mines. I was just using reactor on mines combined with a custom external pillar on the master side (mongodb in that case). Every time I pushed a state on the minions it updated my local mongodb. Since mines, I don't use it anymore.

The reactor : https://docs.saltstack.com/en/latest/topics/reactor/

MongoDB external pillar : https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.mongo.html

Concerning the orchestrator, there is only one case where I need to use it. It is when I am reinstalling my minions (from bare-metal), to automatically re-add the minion key from the minion hostname.

My orchestrator in that case : 

  - deploy a new recipe on my dhcp server

  - deploy a new recipe on a "FAI" host (tftp...)

  - reboot the minion

  - wait for the minion to reconnect

  - automatically re-add the minion

  - deploy highstate and other specific states

Kind regards,

Rémy.

To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/CAOVt49r%3DT_a3EpBdE1exLCF71nPX5O_mZnpVMMVE1tQNYX68yA%40mail.gmail.com.