Parameters cannot be used in tenant names
Description
Gliffy Diagrams
Activity
Stefan Seifert August 15, 2017 at 12:57 PM
Stefan Seifert July 18, 2017 at 9:26 AM
ok - i'll check if this can be supported without unwanted side-effects.
Martin Wehner July 18, 2017 at 9:23 AM
I don't maintain tenant specific parameters outside the tenants but sometimes the primary (and often only) tenant uses the same (host)name as you use for configuring replication agents, cmsAuthorHostname etc.
I guess it's mainly useful for test systems where everything is on one host and you only have a single tenant (which is not uncommon though), but you could also have the case where the tenants all have the same second level domain and you would want to extract that in a common variable.
I have stumbled upon this limitation repeatedly already (and saw configurations from other people referencing this bug as well) and it's just that you would expect parameter interpolation to work in this case as well as for all other values you can declare.
Stefan Seifert July 17, 2017 at 9:16 PM
do you really maintain a list of tenant-related parameters outside the tenant block you want to use in the tenant name as parameter? normally it should be sufficient to keep all tenant-related parameters inside the tenant config block.
and inside this block you can reference the tenant name by ${tenant} - so no need to duplicate it inside the block.
does this solve your problen?
Details
Details
Assignee
Reporter
Components
Fix versions
Affects versions
Priority
Minor
If you use parameter placeholder as the tenant name like in:
- tenant: ${myTenant}it is not properly replaced by the placeholders value during generation.
Being able to use a placeholder would be useful since the tenant is used as the primary hostname and that is a parameter which you often need more than once in an environment definition.