Incorrect Environment Level Variables Used

Hi,

I'm evaluating Otter and there seems to be an issue with the way variables are being evaluated when they are assigned at the Environment level. Say I have 3 environments:

Development
Testing
Production

If I assign a $TestValue variable to each environment with a different value for each one, then I expected that the variables would be evaluated based on which environment the server was in when I run a plan. This doesn't appear to be the case however because every time I execute a plan the value from the "Development" environment is used.

For example, if I set the following values for the $TestValue variable:

Development: DevelopTestValue
Testing: TestingTestValue
Production: ProductionTestValue

and I run a plan that logs the values, the output is always "DevelopTestValue" even if the server is in the Testing environment. Am I misinterpreting how variables work or is this some type of bug.

This may be a bug, or perhaps it's part of the way environment scoping works (we're planning to update this to be more intuitive soon). Can you submit a ticket and attach your Variables (Admin > Variables > Json), Infrastructure (Admin > Export Infrastructure), and Plan text?

Then we will try to reproduce and update from there!

Sorry to tag on to a month-old question, but i'm finding the same thing. Two different environments have the same variables with different values, but when an Orchestration Job is run for two servers, one in each environment, they both choose the same value.

If its any help... variables were using the values from Environment A, so I deleted all variables from A so the plan would use Environment B. Then when adding the variables back to plan A, only the variables from B were used for both servers.

Did anything ever come of this topic or is it a setup problem?

Apologies for the delay - but both cases are indeed bugs that are fixed internally and the fix will be shipped today.

Tod -

Thanks for the update, but after upgrading to 1.5.4 the same Orchestration Plan doesn't appear to look at environment variables anymore when run targeting a server in that environment. The plan errors out with "Could not resolve variable $xxx".

The same plan was working in 1.5.3, just with incorrect variables.

Is the server assigned to multiple environments? If it's only assigned to a single one, then the value for that one environment is used. If a server is assigned to multiple environments, then its values are not considered at all resulting in the "could not resolve" error message.

For that case, you can always assign a system-level variable with a default value of <empty> or something like that.

The server itself is only in one environment, but has multiple roles which span multiple environments. These variables aren't defined in roles so I would think they should still look to the environment of the server.

My apologies... I missed the "orchestration" part and assumed "configuration" plan. What I said applies to configuration plans since those are guaranteed to be in the context of a server (or role) from the start whereas orchestration jobs can target servers, roles or environments, and each can be conflated contextually (think server is in multiple roles and each role or the server itself is associated with a different environment) within the plan at any time. The definite wrong thing to do in that scenario is pick a random environment variable as it was before :)

That being said, for Orchestration Jobs, the job must target a single environment in order to include the environment's variables in the execution.

Are environment variables not brought into context then in an Orchestration Plan when targeting only servers? Only when you specifically target the entire environment? (This at least appears to be the behavior now) I can resolve the variables when running the plan to target the environment. I was targeting by servers before because I don't want the plan to run for all servers or roles every single time. But, targeting by Environment, then by Role may be the answer.

Maybe my understanding for scoping was off and I need to restructure our setup. Thanks for your time.

Just as a follow-up, we are going to clarify this behavior and "fix" it to be more like your use-case, see:

http://inedo.com/support/questions/6290#inline-post-6291