Using raw beacon event data in state.orchestrate

[Chris Apsey]

I'm working on orchestration, and have run into a roadblock with the way that the orchestrate runner handles salt.wait_for_event:

I've got this beacon that looks for valid uuids in the apache2 log (I've edited the log settings so that if this entry appears, it will be the only thing present in the event data)

beacons:
    log:
      - file: /var/log/apache2/access.log
      - tags:
          bootstrap/request/event:
            regex: .*[a-f0-9]{8}-?[a-f0-9]{4}-?4[a-f0-9]{3}-?[89ab][a-f0-9]{3}-?[a-f0-9]{12}

When that event fires, it essentially means that a new minion will report to the master in a few minutes with an id of [role of host]-[some uuid] that's randomly chosen by a php script

That works as expected, and properly fires an event to the master.

What I wanted to do was something like this

## orch/master

...

wait_for_cache_provisioning:
  salt.wait_for_event:
    - name: salt/auth
    - id_list:
      - {{ data['raw'] }} ## <- this value would be a semi-randomized minion id in the format [type]-[uuid], e.g. cache-8342343f-4052-4b9a-b11c-144766741db8
    - timeout: 600

validate_cache_key:
  salt.wheel:
    - name: key.accept
    - match: {{ data['raw'] }}
    - require:
      - wait_for_cache_provisioning

cache_setup:
  salt.state:
    - tgt: {{ data['raw'] }}
    - highstate: true
    - require:
      - validate_cache_key

...

I can't really find a way to access the beacon data without a reactor, but in that case the data wouldn't be available to state.orchestrate, it would just be available to the reactor state(s) that I specify.

My other thought was just to use globbing in salt.wait_for_event in the id_list, but that doesn't seem to be supported.

Can you use raw beacon data in state.orchestrate?  Is there a better way to do this?

Thanks in advance!

[Daniel Wallace]

Sure, just pass it into the orchestration using pillar data.

The state.orch runner module takes a `pillar` dictionary to add to pillar data in the orchestration (know this is not like normal pillar data, since the orchestration is rendered in the context of the master, it doesn't have any other pillar data)

This is just a way to put extra data into the state rendering context.

```

run orchestration:

  runner.state.orch:

    - args:

      - mods: orch.run

      - pillar:

          data: {{data}}

```

and then you can pull the data dictionary out in your state

```

{%- set data = pillar.data %}

```

and then just use it in the orchestration state.

and then you can dump

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/salt-users/43fbc0b0-e2d2-470b-a23e-0ba813c2d0c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Apsey]

Just wanted to comment that I didn't solve this problem in the exact way you described, but you gave me an idea for a more elegant solution using the mine:

I changed my beacon around a little bit to make this scale better:

```

beacons:
    inotify:
      - files:
          /var/www/html/pending_hosts:
            mask:
              - create

```

and then used this reactor configuration

```

reactor:
  - salt/beacon/pxe/inotify//var/www/html/pending_hosts:
    - salt://reactor/publish_pending_minion_id.sls

```

to publish the data to the mine

```

## publish_pending_minion_ids.sls

{% set hostname = data['path'].split('/') %}

publish pending id:
  local.mine.send:
    - tgt: 'pxe'
    - arg:
      - file.read
      - {{ data['path'] }}

```

at that point, I tried to use the mine data in state.orchestrate, but found that the value that was rendered was always the previous value rather than the current one generated by the latest beacon - I forgot that jinja is rendered before yaml, so I had to do this:

```

provision_{{ type }}:
  salt.runner:
    - name: state.orchestrate
    - mods: orch/provision

```

and call a state.orchestrate inside of my main state.orchestrate when I knew that the mine value would already be updated:

```

## orch/provision.sls

{% set host = salt.saltutil.runner('mine.get', tgt='pxe', fun='file.read')['pxe'] %}

wait_for_provisioning_{{ host }}:

  salt.wait_for_event:
    - name: salt/auth
    - id_list:

      - {{ host }}
    - timeout: 1200

```

and all was well.  I did run in to https://github.com/saltstack/salt/issues/34581 which is still broken (just commented to remove the stale tag) and https://github.com/saltstack/salt/issues/48020, which is resolved but not packaged yet.  I manually patched it for now and everything works as expected.

Thanks!