I am happy to make a pull request for this, as I've done this myself, but I'm not a complete terraform export and am not as familiar with your testing requirements / conventions as you might like.
Expected Behavior
Separately named resources for requester/accepter depending on project
Use Case
I have infrastructure that is shared between multiple projects, regions, and environments. One of these resources is our database VPC, which needs to peer with stage, prod, and a test resource (due to some limitations of instance sizes, pricing, and availability, it is a multi-tenant DB)
Describe Ideal Solution
If there was an option of setting:
namespace
environment
stage
name
delimiter
attributes
tags
for both requester and accepter, that would be very useful, as these are not always the same.
I can see supporting the current behavior and the new feature by:
Create module.requester_context and module.accepter_context separately instead of using the module.this
use the var.requester_X / var.accepter_X first, then default to var.X for the module.accepter_context / module.requester_context
use module.requester_context and module.accepter _context instead of your current module.this
that should allow for this repo to support multi-tenant VPC peering, or projects that need to peer between projects/regions/etc.
Alternatives Considered
Set values that expand to both resources, however that breaks tag lookup
Additional Context
Add any other context or screenshots about the feature request here.
Have a question? Please checkout our Slack Community or visit our Slack Archive.
Describe the Feature
Support for multi-tenant peering / peering that spans projects, regions, environments, etc.
The naming convention created by https://registry.terraform.io/modules/cloudposse/label/null/latest -- in the way that has been set up in this repo -- it is assumed these are single tenant.
I am happy to make a pull request for this, as I've done this myself, but I'm not a complete terraform export and am not as familiar with your testing requirements / conventions as you might like.
Expected Behavior
Separately named resources for requester/accepter depending on project
Use Case
I have infrastructure that is shared between multiple projects, regions, and environments. One of these resources is our database VPC, which needs to peer with stage, prod, and a test resource (due to some limitations of instance sizes, pricing, and availability, it is a multi-tenant DB)
Describe Ideal Solution
If there was an option of setting:
for both requester and accepter, that would be very useful, as these are not always the same. I can see supporting the current behavior and the new feature by:
module.requester_context
andmodule.accepter_context
separately instead of using themodule.this
var.requester_X
/var.accepter_X
first, then default tovar.X
for themodule.accepter_context
/module.requester_context
module.requester_context
andmodule.accepter _context
instead of your currentmodule.this
that should allow for this repo to support multi-tenant VPC peering, or projects that need to peer between projects/regions/etc.
Alternatives Considered
Set values that expand to both resources, however that breaks tag lookup
Additional Context
Add any other context or screenshots about the feature request here.