Treat tenant tags as "AND" condition, instead of "OR"?

Legacy Uncategorised
1

Currently, tenant tags are exclusively treated as logical OR when creating a tenant tag filter. Or, at least I haven’t found a way to switch to saying “only tenants that have ALL these tags”.

  1. Is there a way to make tag filtering be ALL of these, instead of ANY of these?
  2. If no, could that ability please be added?
2

Hi!

Thanks for getting in touch! We designed the tag queries to AND across Tag Sets, and to OR across Tags in the same Tag Set. After trialling a lot of different scenarios this seemed to be the best compromise for what is already a complicated system. We found that if you can model your Tag Sets as orthogonal concerns this can work really nicely.

In the cases where you want to model “ALL of these tags in the same Tag Set” I would recommend creating a “composite Tag” which represents all of those individual Tags.

If you can’t pivot your Tagging to fit within the Tag combinations we already support, I’d really like to see more specific details of your scenario.

Here’s a link to our Tag Set documentation in case it helps. :slight_smile:


Hope that helps!
Mike

3

Hi Michael,

The behavior you describe is what I want, but is not the behavior I have observed.

I want to create tags related to hosting, thus:

Hosting Continent: europe, america
Hosting Environment: prod, demo, test
Hosting Pool: pool01, pool02, …

I set up tenants with the appropriate values from these tag sets:

Tenant01: prod, america, pool01
Tenant02: prod, europe, pool01
Tenant03: demo, america, pool01
Tenant04: demo, europe, pool01
Tenant05: prod, america, pool02
Tenant06: prod, europe, pool02

Then, I went to use the tags sets to filter tenants on deployment targets:

us_prod_web01: prod, america, pool01
us_prod_web02: prod, america, pool02
eu_prod_web01: prod, europe, pool01
us_demo_web01: demo, america , pool01
us_prod_db01: prod, america
eu_prod: db01: prod, europe

To take one example:

  • I expected us_prod_web01 to have one tenant according to the tag sets (this would be AND logic across sets): Tenant01
  • Instead, us_prod_web01 has: Tenant01, Tenant02, Tenant03, Tenant04, Tenant05, Tenant06. In other words, the tags are applied as an OR.

This makes tags sets as filters completely useless to me.

4

I am, by the way, on Octopus 3.4.11

5

Hi,

Thanks for getting back to me! I wonder what’s going wrong here - I’m very interested to get to the bottom of it. :slight_smile:

What you are describing is one of the scenarios we wanted to cater for, which sounds like the shared hosting scenario we describe here: http://docs.octopusdeploy.com/display/OD/Designing+a+multi-tenant+hosting+model

Your particular model is slightly more complicated by adding the Hosting Continent and Hosting Environment as tags also, but this should work OK.

I’ve built an Octopus installation with 4 Tentacles to test out a configuration like you’ve suggested using Octopus 3.4.13.

In this screenshot I’ve configured a Tentacle to host Australia Production Pool1 which results in Tenant-01. Tenant-02 is also tagged with Australia Production but Pool2, and it is excluded as I’d expected.

Imgur
u2mGv1x.png1004×723

Imgur
h5bAPUi.png996×649

Imgur
tp6vh25.png1375×544

Imgur
HMyqJrs.png1376×544

You can sign in as a guest to that server and take a look at the configuration I’ve used so we can see what I’m doing different to yourself.

http://52.77.247.202:8085/

I’ll leave this server running for a few days or until we close this ticket out. :slight_smile:

Hope that helps!
Mike

6

OK, now I confess I’m thoroughly confused. I had torn down all my tenants and tag sets on my octopus server after discovering the behavior I described in my initial post.

The combination of that and the inability for deployment targets to be targets of both tenanted and untenanted deployments renders tenants unusable for me.

Based on your examples, though, I went back and recreated tenants and tags on my server, and discovered that the behavior is as you described.

I can only guess one of two things here:

  1. I created these with an earlier version of octo 3.4, and the behavior has changed by 3.4.11
  2. I had my tags set up differently the first time, and maybe I created a case where I had tags that were in opposition of each other and which would combine in such a way as to select more tenants than I thought I was selecting.

Either way, the current behavior of tenant tags is as you have described, so I have to say this one can be closed. I remain baffled, though :slight_smile:

The issue of deployment targets being exclusively tenanted or non-tenanted is still a dealbreaker for me, but that is under discussion elsewhere.

Thanks for taking the time to work through this with me.

Best regards,
Aaron

7

Hi Aaron,

Thanks for getting back to me. I would have very much liked to see the original configuration, especially to see if we could provide better guidance.

It’s entirely possible the behaviour has changed subtly, but we have automated tests based around the query engine and there haven’t been any code changes (that I’m aware of) since we shipped 3.4 with regards to the tenant queries.

Either way I’m glad we can help achieve the model you are after, at least once we support mixed tenanted/untenanted deployments on the same deployment targets, like you mentioned in https://github.com/OctopusDeploy/Issues/issues/2722

Glad I could help work through this with you!
Mike