State inclusion is limited

[ryan-lane]

Currently, in a state I can include other modules:

include:
  - a
  - b
  - c

However, I'm doing ordered runs, and want to be able to define some states, then an include, then some more states, then another include:

Ensure myfile is managed:
  file.managed:
    ...

include:
  - a

Ensure myservice is running:
  service.running:
    ...

include:
  - b

This isn't possible since include is a yaml key and must be unique. It's possible to include the files explicitly via jinja:

{% include 'a/init.sls' %}

But this doesn't allow me to load a module from a different file_root without looping through the file_roots in opt, then checking to see if the file exists, then including it.

It would be nice if include works for multiple calls in a state file.

[basepi]

Hmmm, I'm unsure of how we would do this. As you mentioned before, top level keys in YAML must be unique. I'm open to ideas about how this would look.

[gtmanfred]

The only thing I can think of is it you make include-something, and then we
allow for multiple include strings and match top layer keys of include*
On Aug 12, 2014 5:03 PM, "Colton Myers" notifications@github.com wrote:

Hmmm, I'm unsure of how we would do this. As you mentioned before, top
level keys in YAML must be unique. I'm open to ideas about how this would
look.

—
Reply to this email directly or view it on GitHub
#14899 (comment).

[ryan-lane]

Maybe something like this could work? I know this would look like a state, but that actually kind of makes sense, right?

This is my id for an include of my test sls:
  include:
    - test

This is another id for an include of foo sls:
  include:
    - foo

[gtmanfred]

👍 if it isn't too difficult to implement I think that would be fine, but I have no idea where to stick that in right now.

[basepi]

That is a decent idea. Will take some careful modifications of the state compiler, though, so it's not going to be straightforward (and it may be some time before we implement it).

[eliasp]

+1 for this, to have named include states.

[eliasp]

I have never really worked with the extend statement, but to me it feels like it wouldn't be completely unaffected by implementing "multiple include statements".

Maybe someone with a bit more knowledge of extend's internals can comment on this and outline required changes.

See also: http://docs.saltstack.com/en/latest/ref/states/extend.html

[basepi]

If I'm not mistaken, extend just runs a dictionary update on the original state in the highdata structure with the new arguments and so forth. I think as long as your extend was defined after your include you would probably be fine, but it should definitely be something we pay attention to when we implement this.

[ryan-lane]

So, funny enough I was wrong about how the jinja include works, and it actually does exactly what I want.

This will include the sls files in the order specified, from multiple file roots:

Ensure myfile is managed:
  file.managed:
    ...

{% include 'a/init.sls' %}

Ensure myservice is running:
  service.running:
    ...

{% include 'b/init.sls' %}

[basepi]

Ooh, good workaround. I'll still leave this open, as I think it would be something useful, but at least we have a good workaround for now.

[ryan-lane]

So, this workaround isn't wonderful. One issue is that normal includes allow you to define the include in multiple locations and it'll deduplicate the include. If you use a jinja include, it pulls all the states into the current scope, which means you'll get duplicates if you use the jinja include in more than one spot.

It would be really nice to properly support this. It's a bit painful doing sequentially ordered states without it.

[anlutro]

I suppose the only way to truly achieve this is to split each part of the state into its own SLS files and do a nested set of includes that way.

Here's a workaround that prevents duplicate states, but doesn't preserve order.

{% set includes = [] %}

Ensure myfile is managed:
  file.managed:
    ...
{% do includes.append('a') %}

Ensure myservice is running:
  service.running:
    ...
{% do includes.append('b') %}

include: {{ includes | json }}

[ryan-lane]

I think includes in this situation would still be executed out of order,
since you're using the include directive, which will occur before the
current module.
On Aug 5, 2015 5:57 AM, "Andreas Lutro" notifications@github.com wrote:

Here's another workaround that prevents duplicate states.

{% set includes = [] %}

Ensure myfile is managed:
file.managed:
...{% do includes.append('a') %}

Ensure myservice is running:
service.running:
...{% do includes.append('b') %}

include: {{ includes | json }}

—
Reply to this email directly or view it on GitHub
#14899 (comment).

[maatthc]

Having multiple 'include' to order execution would be perfect!
We have hundred of States that could be much simpler without all the dependencies declaration what makes Salt extremely verbose.
Any chance to implement this feature?

Cheers

[mikemartino]

+1 for this, to have named include states also.

[soostdijck]

+1 for this, for now I'll go with the workaround...

[ghost]

+1 for this, to have named include states also.

[th31nitiate]

I think the best option here might just be to concatenate the list of all includes found then perform execution of those. The only issue occurs when we think of the order of execution. I believe that can be fixed by appending some sort delimiter in the list, it would use similar code logic as that used in the requisite section. The delimiter would have to be invisible to the user but salt should be aware of it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[johncollaros]

Any news on this issue?

[felixmarch]

Maybe something like this could work? I know this would look like a state, but that actually kind of makes sense, right?

This is my id for an include of my test sls:
  include:
    - test

This is another id for an include of foo sls:
  include:
    - foo

Any news on having this feature? :(