Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Compound targeting includes unexpected targets in the result #49205
Description of Issue/Question
Compound targeting includes unexpected (even nonexistant) targets in the result.
This was triggered by an orchestration that rejects a salt minion in the middle of the orchestration. The
Consider the following minions:
Now, we can write an orchestration:
Steps to Reproduce Issue
Run the orchestration. It works as expected:
Now, if we reject this minion:
Now let's try to run the same orchestration again:
And this is where this behavior differs from
In general, and as discovered later when debugging this issue if you filter out any non-existing minion id, it will be included in the response, as:
Master and minions are all in the same version.
@gtmanfred Thanks for your fast response! I've recreated the environment, so the minion ids won't match the initial issue report, sorry for that. I rejected minion id
I fear the only way to include "new" (as in unknown to salt) minion ids is using the list matcher and the compound matcher by extension. The rest of matchers seem to only work on the subset of well-known minion ids, and thus, are not affected from what I can see.
so, the last one you did there, is the expected behavior, that was added in 2018.3.
If a minion is targeted in a list, and it does not exist, we print an error. That was a feature request from someone else.
The bug that I see is when using a
This makes a lot of sense, yes.
Exactly. The issue I'm referring to explicitly targets the use of compound matcher, not the raw list matcher; I just noticed I kind of inadvertibly implied that the last case was wrong, didn't mean to.
So, I completely agree that the issue is with the compound matcher using a list with excludes (
Cool, @saltstack/team-core who was it that added the feature that the list matcher would print a no response from a minion if it was included, but didn't actually exist?
I think there might have been a bug added when that was used with