I’m playing round with the new tennant features. So far looking very lovely. Few quick questions:
a. I got an error indicating I can’t mix tennant and non tennant deploy to the same server. So basicly when i have tennants assigned to a server I can’s deploy non-tennant to that specific server. Basicly this mean i need to setup more servers. That is correct?
b. Is there an option that I can have a tennant login in to the portal and push its specific project through the OTAP stages?
a. You’re correct, through the beta period we allowed you to mix-and-match tenanted and un-tenanted deployments on the same deployment target, but we discovered this was a dangerous default. You could inadvertently add a new deployment target with no tenant filter, and ALL tenants would be deployed to that target, breaking whatever isolation you may have designed for your deployments. We decided not to allow mixing and matching as “safe-by-default”.
The workaround you can apply is to create more servers (as you suggested), or alternatively create a second instance of Tentacle on the same target server - one for tenanted deployments and one for un-tenanted deployments. Would that suit your situation?
Thanks for your respons. I understand the reasoning behind not mixing tenant/non-tenant deploys on one server. I will give your proposed work aorund a go. I didn’t know we could create multiple tentacles to on eserver.
I will give the account manager concept a go, and see what the folks think about it.
We have just upgraded to 3.4, and I was looking into using tenanted deployments for our current project. Now that I have seen this, though, I will have to put that on long-term hold. While we can theoretically add instances to every machine (as most of our machines are shared between projects), this also means the nightmare of port opening requests/connection testing to all machines in all different countries, etc. The only other option is to move every project to tenanted at once, which is also a huge effort and coordination.
I’m not sure that the decision to restrict the deployments is really the best, though I understand the risks. On the other hand, it seems ridiculous to have a duplicate of every deployment target if you have, for instance, one project which has a common configuration for all tenants, and then another project which has tenant-specific configs. I think a common supporting service, for instance, is a common scenario, even in multi-tenant installations. The overhead for managing this seems unwarranted.
Also, when performing a tenanted deploy, are targets without a tenant filter even selectable as deploy targets? If not, then how is it possible to inadvertently deploy to a new target with ALL tenants? If so, then how does prevention of mix and match act as a safety measure?
In other words, if I perform a tenanted deploy from my project, then why not just prevent it from deploying to targets without any tenants assigned? And if I deploy that same (or another) project using untenanted, then it should just not care about any assigned tenants on that target, and proceed as normal.
Thanks for getting in touch and thinking through this from your perspective. In the earlier design, targets with no tenant filter were treated as “anything goes” targets - Octopus would place no restriction on the target - which was the reason for the potential danger of leaking, and why we switched to a more defensive calculation for which targets to include.
At the time we didn’t differentiate between tenanted projects and untenanted projects. We recently added the project’s Multi-tenant deployments mode, and could use this to modify the calculation.
I was toying with a similar idea I think you’re suggesting - the tenant filter on a deployment target could be considered when deploying a tenanted project, and completely ignored for untenanted projects.
This would enable the situation I think you’re describing where you have a common/shared service you’d like to deploy alongside tenanted applications on the same host.
Thank you - it seems you understand the situation precisely. As a guest user I can’t see the error that you mention on the demo server, but that’s ok - I am sure this is exactly what we would see if we attempted what we need to do.
I think the solution as you mentioned it:
the tenant filter on a deployment target could be considered when deploying a tenanted project, and completely ignored for untenanted projects.
is perfect (by “completely ignored” I assume you just mean have no effect on the variables, but can still be used as a target). This also gives us a clear migration path for those projects which are not currently configured for tenanted deploys, but will be some day. It means they can continue to deploy as-is (environment-based), and we can convert another project to tenanted while still deploying to the same targets. Finally, projects which we will never want to convert to tenanted (ie. common API endpoints, shared storage apps, etc.) will simply remain as-is forever.
Incidentally, I just ran into another case where we could really use multi-tenanting, but are blocked by this issue. As it is currently implemented, the multi-tenant feature is a non-starter for us due to the current design.
The idea we’re considering is to add a configuration option to Deployment Targets and Accounts that let you control how Octopus treats them during tenanted or un-tenanted deployments. This would be complimentary to how the Project can control what kinds of deployments it will perform, tenanted, un-tenanted, or both.
For example on a Deployment Target, when the multi-tenant feature is enabled for the Octopus Server, we could add these options:
Tenants
Disable tenanted deployments (default)Any tenant filter would be cleared and disabled/ignored since this target should be excluded from any tenanted deployments.
Allow deployments with or without a tenantBoth tenanted and un-tenanted deployments will use this target. The tenant filter would only apply for tenanted deployments.
Only allow tenanted deploymentsOnly tenanted deployments where the tenant matches the tenant filter should use this target. An empty tenant filter means ANY/ALL tenants can use this account/target.
After thinking this through I believe combining the Project, Deployment Target, and Account “multi-tenancy” setting with the power of Roles should enable the scenarios we’ve discussed so far.
Of course, the proposed solution would fully meet our needs. Can you further elaborate on the use case of a tenanted deploy to a server without any tenant filters, though? Is it simply the avoid having to list all the tenants on one server by hand? If so, isn’t that different than the way that roles work? Why the inconsistency?
We do have cases throughout Octopus where an empty list means “ANY” and others where it means “NONE”.
For example, Environments and Roles of Deployment Targets are considered primary properties, without either having some kind of value the Deployment Target would never be used in any deployments.
On the contrary Variable Scoping, choosing when to run a Step in a deployment process, scoping an Account to an Environment, and other places, these lists are treated more like a filter. In this case “empty” means “global scope” or “anything goes”, or you can narrow the scope by adding some kind of filtering. As you mentioned, treating the empty list this way is a convenience for listing all of the “things”.
We were planning to treat the Tenant filter on Deployment Targets and Accounts similar to the Environment filter on Accounts, and the other examples I gave above.
I am using 3.4.5 and having issues with this limitation, too. Which is so unfortunate since I just bought a license.
The proposed solution would work for me though. How can I make an impact so that this gets implemented sooner rather than later since it a big-enough inconvenience?
Thanks for getting in touch. The fact we know you are also interested in a solution is enough. It is already on our backlog and you can track that GitHub issue and get involved in the design conversation.
The workaround with a dummy tenant will work for us at this time. I just want to add my voice in support for this enhancement.
Here is one more use case for multi-tenant deployments into your collection. Our development workflow is based on git feature branches and code reviews. Code reviews often require a running code in order to fully comprehend a feature under review. We plan to use feature branches as tenants and manipulate tenant management and deployment through API on our build server. In this case we want to use un-tenanted deployment for master branch and tenanted deployment for feature branches.
As a workaround we’ll need to create a “master” tenant but it complicates the promotion of releases to the next environment which does not have tenants because only master builds are promoted there.
Thanks for weighing in on the conversation! I worked on a similar deployment system recently where we had the same topology. We ended up opting to make the “master” deployments use a Tenant anyhow because then all of our deployments used exactly the same process, same variable system etc.
I would be interested to see some screenshots and your thoughts once you make your project purely multi-tenanted. What you think is working for you, and what you think is hindering you.
Add another customer to your list who want the ability to mix tenanted and non-tenanted work on deployment targets, please.
Our use case is this:
we have a whole bunch of operations-related deployment projects that are tenant-agnostic, but operate on machines that have tenanted applications installed
we also have deployment projects that we want to make tenant-aware.
The limitation of all-or-none for tenanted deployment targets makes tenants a non-starter for us.
I’ve seen the workaround of a dummy tenant, but frankly, we have too many deployment targets and too many projects to make the amount of work to set that up be viable.
It’d be much better to recognize that people need to be able to do both on the same target
Thanks for weighing in on the topic. This is at the top of our radar for improving multi-tenant support. The best place to get involved is over in the GitHub Issue: https://github.com/OctopusDeploy/Issues/issues/2722
We will be proposing designs and commenting on progress.