I am looking to understand the role of tenant tags in a deployment. In my Octo setup I have a tenant lets call it TenantA defined against an environment lets call EnvF. I have defined a tag set connected to TenantA with Tag1, Tag2.
I have connected TenantA to ProjectP. I have 2 servers in present in EnvF. Server1 is tagged with Tag1, Server2 is tagged with Tag2.
When I go to run a deployment of ProjectP. I select the environment EnvF, I select TenantA, and further I select Tag1.
When I look at the list of affected machines in the deployment, I see both Server1 and Server2 listed as being affected by the deployment. My expectation was that Server1 would be the only machine that would be picked based on my tenant tag selection. Is that not a valid configuration? If I execute the deployment it very clearly affects both Server and Server2 in the process, so it does not appear to be a UI bug as was mentioned in another post.
That sounds very similar except I just have 1 tenant and 2 tags, and each deployment target has just one of the tags applied to it. Given I was selecting both the tenant and the tag I select just the tag now, but the UI still reflects both Server1 and Server2 as being targeted for deployment. After executing the deploying it did in fact affect both Server1 and Server2 so it does not appear to be this issue:
Is it the case that selecting the tenant tag gets you the tenant(s) selected for deployment, and then all connected machines of the tenant(s) are automatically deployed to?
I should note I did have the Tenant TenantA PLUS the tags applied to each machine, so Server1 was tagged With TenantA + Tag1, Server2 was tagged with TenantA + Tag2 I removed the TenantA option and just left the tenant tags on the deployment targets, I am still getting both machines when I target just Tag1 with no Tenant selected.
Thanks for getting in touch! That’s good to hear you’ve found some clarification on this behavior. I’m sorry about the confusion this has caused!
“Is it the case that selecting the tenant tag gets you the tenant(s) selected for deployment, and then all connected machines of the tenant(s) are automatically deployed to?”
You’re correct, the behavior is additive. As Daniel wrote in the thread you linked to, it’s
designed to accommodate larger and more complex Tenanted deployments.
This means since your tenant is included into 2 separate tags, where each is assigned to a separate server, both servers will be deployed to when targeting this specific tenant. To avoid this, you could assign specific tenants to each machine instead of a tag, or reconfigure your tenants so they’re not in multiple tags that are assigned to separate machines.
It sounds like you’re on the right track. Let me know how you go or if you just have any additional questions or concerns going forward.
I was eyeing the bullet “you want to provide isolated, time-limited, deployments for work on feature branches”
In our company we have many engineers that spin off branches of master. Ideally I wanted to manage a single “Feature environment” in Octo Deploy to support their needs. The idea was in our pipeline a branch could be opted to be deployed to this “feature environment” and if one did not exist or was not available, since we are using AWS we would stand up a new VPC and new instance and deploy the code. I was translating that as the following process
Automatically register instance to Feature environment
Create a new tag in the tag set library for the new environment
Upon registering the new instance, apply the newly created tag to it
The build pipeline would create a release and deploy, targeting the tenant tag.
That was kind of what we were trying to do, but given how tags actually work now that I understand it better that is not something we can achieve. I guess it would be helpful to know with respect to a new tenant in an environment, is it more expected that you would have a fixed number of these? It seems like creating a new tenant on the fly is more cumbersome than what I highlighted above, at least for us. When we create a new tenant, that would mean for us altering a number of variable sets both at the project as well as the library variable set level each time we create a tenant. Although behind the scenes the configuration would largely be identical as each tenant is its own VPC in AWS with identical components/configuration. Perhaps that would be a use for tenant tags for us. Could I just create new tenants and make sure they have a consistent tag, and then define variables against the tenant tag instead of the tenant itself so we can just add tenants as needed? Even then that is heavy for us because I have 20-something projects that a new tenant needs to connect to so trying to create this on the fly just feels cumbersome, is that what other companies, customers normally do when working with tenants?
