Declaring dependencies, or, Extend/Watch hell

[David Bishop]

Prep work before reading the rest of this email: read https://github.com/saltstack/salt/issues/631

So, as everybody obviously read that issue before reaching this line, we can talk about declaring dependencies. As you can see, dcolish came up with a way to make that specific example work. However, I immediately ran into exactly the same problem with the way we do our apt setup, which you can see at https://gist.github.com/2131670. I say exact same, but it's subtly different - different enough that I wasn't able to figure out how to apply dcolish's solution to the new problem (this time there is a static file on top of the dynamically generated list of files that need to notify the apt-update cmd). That is undoubtably a reflection on my poor programming skills.

The general problem that we're trying to solve, however, is: how do we declare that one resource should tap another one on the shoulder when it gets updated, or vice-versa. I know the "p" word is verboten, but puppet actually handles this fairly nicely. You can declare many-to-one, one-to-many, declare from the perspective of the notifier, or from the perspective of the notify-ee, depending on which makes sense and is more convenient. You can declare whether a resource *just* depends on another resource, or if it should get notified when the other resource changes. And, more to the point, in any moderately "real-life" configs, you're going to need pretty much all of those things.

So - we're not at 1.0.0 yet. I fully realize that not all features can be completed at once and perfectly. But I do think we should at least start talking about how this should be addressed, and where in the roadmap it falls.

If, as is often the case, I have stuck my foot in it and either 1) this is a solved problem and I just missed the solution or 2) this discussion has already been had, and it's on the roadmap, and I'm just dumb, please let me know. I handle being told to shut up quite well.

Thanks!

David Bishop

[Thomas S Hatch]

If the extend capability as it lies wrt multiple keys it the problem then I think that the solution would be to offer an embedded extend. so the ability to place an extend statement directly within an id.

I think I should say that we should be able to append requisites from other states, since extend does not make sense there, extend works well as a catch all. But yes, it seems you want a shortcut to add requisites.

so something like this:

http:

  service:

    - running

tomcat:

  pkg:

    - installed

    - require_in: 

      - service: http

Is this something that will fulfill your needs? Since we really should not use a notify, since it does not follow the Salt States execution model

- Thomas S Hatch

[David Bishop]

> If the extend capability as it lies wrt multiple keys it the problem then I think that the solution would be to offer an embedded extend. so the ability to place an extend statement directly within an id.
>
> I think I should say that we should be able to append requisites from other states, since extend does not make sense there, extend works well as a catch all. But yes, it seems you want a shortcut to add requisites.
>
> so something like this:
>
> http:
> service:
> - running
>
> tomcat:
> pkg:
> - installed
> - require_in:
> - service: http
>
> Is this something that will fulfill your needs? Since we really should not use a notify, since it does not follow the Salt States execution model

In your example, if salt had to install tomcat to satisfy the state, would it result in a restart of the http service? And if so, how is that different from just saying "notify"? Maybe I don't understand what "require_in" means...

David

[Evan Borgstrom]

On Tuesday, March 20, 2012 2:13:40 AM UTC-4, Thomas Hatch wrote:

If the extend capability as it lies wrt multiple keys it the problem then I think that the solution would be to offer an embedded extend. so the ability to place an extend statement directly within an id.

I think I should say that we should be able to append requisites from other states, since extend does not make sense there, extend works well as a catch all. But yes, it seems you want a shortcut to add requisites.

so something like this:

http:

  service:

    - running

tomcat:

  pkg:

    - installed

    - require_in: 

      - service: http

Is this something that will fulfill your needs? Since we really should not use a notify, since it does not follow the Salt States execution model

That does fulfill our needs. The name and semantics of it are really neither here nor there to us as long as the end result is a way to influence one state item from within the definition of another so that multiple state items within the same file can all update the same target.

-E

[Thomas S Hatch]

Ok, I am going to see if I can get this into 0.9.8.

I don't want to call it notify, since it is not notifying anything, it will just extend the other state's require or watch statements