Dirty tenants

[Jay]

Hi OD,

Do you have any plans to prevent updating dirty tenant variables? We’re deploying multiple products in our suite through the multi-tenanted approach and we have multiple teams/people performing these deployments. If users A and B both open a tenant’s variables and user A updates the configuration for one project followed by user B updating configuration for another project, user B “wins” and user A loses their changes (given they haven’t yet cut a release). User A won’t have any indication that their changes were lost until they deploy.

Is there something you can do to prevent this?

We’re considering restricting users from manually changing variables in OD altogether and instead keeping/maintaining our configuration management in source control.

Perhaps Spaces will at least lower the likelihood of a conflict but some kind of dirty read check pre-update could be helpful.

Thanks,

Jay

[TomPeters]

Hi Jay,

Sorry you hit this issue. I can see how annoying that would be.

I’m certain we will do something about this at some point but I can’t give you a time frame right now. This is most likely to be resolved as part of our Variable Unification project that we are planning. You can track that Github isssue to monitor our progress.

In the meantime I think you are right that Spaces may help, but only if you are willing to have multiple Tenants across your set of Spaces. This would be equivalent to splitting up your current Tenants, so that you have a separate Tenant per project (for example).

Hope that helps.
Regards,

Tom