we’ve recently upgraded from 2.6 to 3.16 and I’m reviewing your multi-tenant support in the hopes we can transform our configuration to take advantage of those new features.
For the most part, the conversion is fairly straightforward, but I am having an issue with our authorisation rules. To illustrate, we currently support a one-project-per-customer model. In the project variables, we keep configuration that differs from one customer to the next. Each project is linked to multiple library variable sets: a “Global Variables” set which defines configuration that’s true for each deployment, a “Currency Codes” set with a hundred or so mappings of currency-code-to-country-code mappings and an “Authorisations” set per customer. Each of these library variable sets may differ per environment and/or over time.
Logically, the Authorisations library variable sets could each be merged with the associated project variables in that they’re each linked to only one project. Pragmatically, they’re separated into library variable sets because there’s a couple hundred of them per customer and (before you improved the variable filter functionality) they were difficult to filter out.
Generally speaking, in adopting a multi-tenant layout, the project variables become variable templates largely informed by the tenant and the “Global variables” library variable set become project variables. An easy enough switch via the API. However, in this model our hundreds of authorisation rules (per customer) need to become tenant variables that are defined as variable templates of the project.
My problem is that the Project Variables tab on each Tenant screen is MASSIVE. Each environment has over 100 variables to fill out and none of it is filterable/searchable.
I attempted to create a new library variable set, with only authorisation rule templates in it, link that to the existing authorisation library variable set via tenant tags, but that presented problems with environment-level scoping.
As it stands, I can’t sell multi-tenancy to our support/deployment teams. Do you guys have any suggestions on how I can structure our CM in a multi-tenant structure which doesn’t introduce a maintenance nightmare?
Thanks for getting in touch! I’m terribly sorry about the delay in getting back to you. I’ve had a couple discussions with my team concerning your questions.
Firstly, you’re correct that library variable templates can’t be scoped to an environment, so unfortunately that’s not possible if you need environment scoping.
You make a good point regarding the UI of the tenant variables page being unfriendly for large numbers of variables like in your scenario. The only workaround we can think of for the moment is to manage these authorisation variables as JSON or XML, and store the entire set for each tenant as a single variable. This would resolve the large number of variables, but it depends on whether you can modify your process to work with this.
This point you raised has started a conversation about re-thinking the tenant variables page to make it more usable for large numbers. It’s currently ongoing, but I’ll be sure get back to you soon with any updates regarding this.
I hope this helps for the time being! I’m sorry it’s not better news, but thank you for bringing this to our attention. It really helps us work towards continually improving Octopus.
Just following up after some more discussion. I’ve created the following issue to address how this page behaves in a scenario with a large number of variables.
We’re currently working on completely overhauling our UI for the upcoming 4.0 release, so this will be addressed after that release. If you’re interested in checking it out, we’ve shown some of the UI changes as they are right now in our most recent TL;DR meeting, and you can see that in action here.
Don’t hesitate to reach out if you have any further questions going forward.
at first, I thought the JSON/XML suggestion might only make things more cumbersome, but you’ve prompted me to return to the variable substitution documentation and I note that you now have native JSON parsing (we’ve come from 2.6). It might actually be a better, more manageable, solution than our current one-variable-per-authorisation-rule approach since they’re all of a kind. I’ll try to sell it to our support teams.
That said, even were our authorisation rules reduced to one variable per customer, we still have over 100 variables which will make the tenant variables pages unwieldy. So I’ll be following your raised issue closely. I watched the 4.0 video you linked, by the way, looks very promising.
Thanks very much for your considered response and suggestions. I’ve been repeatedly surprised by the responsiveness and extra mile effort of the OD support staff. You guys are great.