Scoped variable becomes global when machine removed

Summary: has the potential to produce unexpected configuration values during a deployment

Setup:
1 Environment
3 Machines with 1 role each
Server1 has role QLD
Server2 has role NSW
Server3 has role VIC
1 Project
1 Process step (deploy asp.net website from nuget package)
Application has configuration entry:
key=“State” value=“QLD”
(because Queensland is the best state so it is the default :-D)
2 Variables applied to config during deployment
name=“State” value=“NSW” scope="Role:NSW"
name=“State” value=“VIC” scope=“Role:VIC”

Problem:
Remove the VIC machine
This removes the VIC role
This changes the 2nd config entry to name=“State” value=“VIC” scope=""
Next deployment sets State=“VIC” on Server1 (the QLD server)

Expected:
Variable scope restriction remains but is flagged as invalid
or user is warned of the consequences of removing the machine with the role
or roles are managed independently from machines having those roles (i.e. CRUD the roles then assign to machines)
or variable rule for VIC is removed completely

Workarounds:
Add variable values for all scoped roles
Review all variables before removing a machine that is the last machine with that role

When removing a machine which shares a role with another machine the behaviour is correct, it is only when the last machine with that role is removed that the behaviour is unexpected.

NB: this is a minimal example of a setup that would replicate the issue, for details of the actual setup see the document that I will send Mark
Originally discovered in: 3.2.15
Confirmed in: 3.2.23
Server: Server 2012 x64 with TFS 2015 installed, local SQL Express (shared with TFS)
Network: Corporate domain behind proxy
Chrome Version: 48.0.2564.109
License: Currently still on trial

Hi Ed,
I have done a little experimentation around this behaviour and come to the conclusion that although behaviourally the variable scoping is all correct, the UI is acting in an counter-intuitive way.

When you remove the last machine with a role, the role scope information actually just become hidden on the variables page. This is due to user requests where unnecessary role information was showing against variables that were no longer applicable. Unfortunately, as you have discovered, the result of this is that it isn’t completely obvious that the scopes are still attached to the variable in the database.
If you go ahead and perform a deployment you should notice that the variables are actually not globally scoped since the “hidden” role is actually still taken into consideration.
This leads to obvious confusion and possibly result in users modifying the wrong variables.

I have created GitHub ticket #2387 to get this UI fixed so that this confusion can be avoided. Feel free to keep an eye on this ticket to see when it progresses.
Thanks for bringing this issue to our attention.
Cheers
Robert

Ahh sweet. Yeah the flipside of this is another ticket I was going to raise. If I am adding a machine to an environment with a new role ideally I would like to do all of the configuration for that machine before adding the machine.

Going back to my example if we wanted to add ACT but wanted to configure all the configuration values and rules before adding the machine (in case a deployment goes out, maybe we’re adding it to production and a hotfix is required when the machine is half added).

The current way of managing only roles that exist on machines is very clean and simple for simpler setups but possibly at the cost of more complex use cases.

Hi,
Thanks for your ideas on the topic. At the moment the work around for this could be to create the machine, mark it as disabled, then add the required role. The role will then be able to be used throughout the system and once you are happy with the configuration you could go back in and enable the machine. In order to make this process a little more efficient I am raising the suggestion with the team to allow creating a machine already in the disabled state. If this feature is approved it will go into our ticket backlog to be actioned at some future date, in consideration of other priorities. I will send you through the ticket details if this takes place.
Thanks again,
Robert