Unable to "watch" a state which is a "prereq"

[jacksontj]

If i have a state (file.managed below) which is a prereq_in it cannot be watched by another state. The below SLS file causes infinite recursion-- which doesn't make a ton of sense to me. If i am watching a state it shouldn't matter if that state has a prereq-- just if it changed or not, unless i'm missing something.

remove_from_lb:
  cmd.run:
    - name: /home/thjackso/tmp/rotation/oor.sh

# Command to add host to LB
add_to_lb:
    cmd.wait:
        - name: /home/thjackso/tmp/rotation/ir.sh

/home/thjackso/workspace/salt/atsdeploy/test/haproxy.cfg:
  file.managed:
    - source: {{ salt['pillar.get']('haproxy:source', 'http://localhost/cfg/default') }}
    - user: thjackso
    - group: eng
    - mode: 644
    - source_hash: {{ salt['pillar.get']('haproxy:hash', 'md5=7822bba98f950fc9e12e1211548fd730') }}
    - prereq_in:
      - cmd: remove_from_lb

haproxy:
  service:
    - running
    # remove from LB if you have a change
    - prereq_in:
      - cmd: remove_from_lb
    # add it back when you are done
    #- watch_in:
    #  - cmd: add_to_lb
    - watch:
      - file: /home/thjackso/workspace/salt/atsdeploy/test/haproxy.cfg

[jacksontj]

You get the same outcome with the direct approach--

remove_from_lb:
  cmd.run:
    - name: /home/thjackso/tmp/rotation/oor.sh
    - prereq:
      - file: /home/thjackso/workspace/salt/atsdeploy/test/haproxy.cfg
      - service: haproxy

/home/thjackso/workspace/salt/atsdeploy/test/haproxy.cfg:
  file.managed:
    - source: {{ salt['pillar.get']('haproxy:source', 'http://localhost/cfg/default') }}
    - user: thjackso
    - group: eng
    - mode: 644
    - source_hash: {{ salt['pillar.get']('haproxy:hash', 'md5=7822bba98f950fc9e12e1211548fd730') }}

haproxy:
  service:
    - running
    - watch:
      - file: /home/thjackso/workspace/salt/atsdeploy/test/haproxy.cfg

[basepi]

Thanks for the report -- I'll have @thatch45 look into it.

[jacksontj]

Any update?

[basepi]

I'll bug @thatch45 for an update tomorrow.

[thatch45]

I am glad this was so simple, but this was happening not as an artifact of watch but of all requisites! This patch fixes it for me, please double check. (I finally had a solid 4 hours to track this down)

[jacksontj]

I just tested it an I now get an error saying that one of the states is recursive (http://pastebin.com/Fxzi3BSR), so definetly better ;)

[thatch45]

This was surprisingly easier then I thought once I realized that all of the data is already available for the cross check and that I just needed to put the right data in the pre dict! On my end this looks like it is working the way it is intended to, can you take it for a spin @jacksontj ?

[jacksontj]

Beautiful! Yea, the prereq state is the only "unidirectonal" relationship in the requisite system-- so it gets handled differently ;) That works for me-- i'll have to do some more testing around the in-rotation stuff afterwards-- but the state above does what it is supposed to. Thanks again @thatch45 !

[jacksontj]

I imagine this'll make it into 0.16.3?

[basepi]

Yes, already cherry-picked. =)

[jacksontj]

When is that release scheduled to go out? A week or so? (curious)

[basepi]

We're planning on cutting the release in the next hour or so, then we'll give the packagers a couple of days to actually package it. Expect the announcement early Monday (though it will be available on PyPI later today)

[jacksontj]

Awesome, I'll hold of on my internal release for that ;)
On Aug 9, 2013 9:59 AM, "Colton Myers" notifications@github.com wrote:

We're planning on cutting the release in the next hour or so, then we'll
give the packagers a couple of days to actually package it. Expect the
announcement early Monday (though it will be available on PyPI later today)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6057#issuecomment-22408474
.