I can then update the variables snapshot for the release to pick up the change and I get the correct value (i.e. from the 3rd row).
Then I can remove the 01 tag from the 2nd row, update the release again, deploy and voila! I still get the correct value; even though the configuration was the same before I added then removed the 01 tag form row #2.
In every instance, the release I’m deploying is deployed with filters from different tag sets referencing variables all in the same library variable set (no project variables):
tenant tag set, tag 110
ShipStation-Dev tag set, tag SS-Dev-Legacy-DB
DDE-ON-Z-OR-Y tag set, tag Z
My understanding of the correct behavior is that on the first deployment of the release created after I added and saved the 3rd row, Octopus should have picked up the value of the 3rd row. It didn’t, it picked up the 2nd row even though the release was deployed with the DDE-ON-Z-OR-Y tag set, tag Z . The really freaky issue is not how Octopus interprets the scope, but that it behaves differently under the same scoping. Before and after as I described
Great to hear from you again and thanks for reaching out about your variable set scoping bug.
This certainly appears like unexpected behavior. We are currently setting up a repro of your reported issue. We will touch base with you shortly, once we have some findings.
It looks like the problem you are encountering here is not exactly a bug. The tenant tags in this instance are working as designed, they just don’t function very well for this type of variable scoping.
Tenant tags work similar to our machine roles in that they are essentially used to logically group tenants together for more convenient selection during deployments. Octopus acts on scoping tenant tags inclusively, rather than exclusively.
This means that adding multiple tenant tags won’t provide a more specific variable scoping. This also explains the somewhat random behavior you’re experiencing when changing the values and scoping. Octopus technically considers each value to be valid, so it doesn’t really know which one to use.
When you need to use specific variable values for a specific tenant during a deployment, you should aim to use the tenant variables feature. This feature allows you to assign variable templates to the tenants themselves. You can then define a specific value per tenant and environment.
Let me know if this helps or if you have any further thoughts or questions at all.
No worries at all! I am going to look into whether we need to perhaps make some clarification in our documentation on this. We couldn’t really find a great explanation for this specific behaviour in our documentation.
Anyway, feel free to get in touch at any time if you ever have any further questions or thoughts.
Thanks for your follow-up. For now, I’m going to stick with straight variable scoping because the tenants are dynamically created and destroyed frequently, which means I’d need to update the automation to create the tenant variables. Secondly, the Octopus project is used for a half a dozen environments and the dynamic tenants are just one of those. Therefore, I don’t want to start creating tenant vars that are only relevant to one environment and not the others. Not that it might be the best approach, but the change to get there is significant where as I can get the variable scoping to work if I update the scoping according to the sequence I described in the problem above.
Frankly, the issue does seem like a bug to me, and the rule that assigns var values according to the greatest specificity is a natural way to think about it imho, i.e.
var1 xyzts1:a, ts2:b
var1 efgts1:a, ts2:b, ts3:c
Tenant One - ts1:a, ts2:b
Tenant Two - ts1:a, ts2:b, ts3:c
It seems natural and logical to me when deploying to the tenants above that the xyz value will be used for Tenant One and the efg value will be used for Tenant Two.
I would be interested if you could provide an example where this would not be desired? I don’t think the comparison to roles is equivalent because you can’t provide (“include”) multiple var values at the same time, but a single deployment can be made to (“include”) multiple roles. In other words, where only a single value can be provided, there should be rules that prevent any arbitrary decision as to which value is provided. The rule of OR within tag sets and AND across tag sets applied here would do just that.
Thanks for getting back. This behaviour probably isn’t the most desired way to handle it on our end and I agree that it isn’t intuitive that we don’t AND the tags here. However, the code responsible for it touches nearly every part of Octopus. This isn’t so much a bug, or something that we can easily fix, as it’s more of a limitation baked into the software due to how we handle scoping specificity. I believe this limitation was one of the reasons for implementing the tenanted variables feature in the first place.
I know this answer isn’t very helpful in your situation and I apologize for not having a better alternative for you to manage the variables on your tenants.
If you have any further questions or thoughts on this, please don’t hesitate to let me know.
