Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Allow tenant selection when creating Dashboard Objects #97

Closed
spacez320 opened this issue Oct 11, 2023 · 2 comments
Closed

[FEATURE] Allow tenant selection when creating Dashboard Objects #97

spacez320 opened this issue Oct 11, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@spacez320
Copy link

spacez320 commented Oct 11, 2023

Is your feature request related to a problem?

The Dashboard Object spec provides a nice way to inject index patterns/visualizations/dashboards, but it seems like it's only able to provide these resources to the global tenant.

What solution would you like?

Specifying the tenant to target for the Dashboard Object. Possibly other resources?

E.g.

resource "opensearch_dashboard_object" "test_index_pattern_v7" {
  body = <<EOF
[
  {
    "_id": "index-pattern:cloudwatch",
    "_type": "doc",
    "_source": {
      "type": "index-pattern",
      "index-pattern": {
        "title": "cloudwatch-*",
        "timeFieldName": "timestamp"
      }
    }
  }
]
EOF
  security_tenant = "my_tenant"  # Add this.
}

What alternatives have you considered?

It seems like you can generally specify tenancy in direct API calls by doing something like providing security_tenant=<something> as a URL parameter. For now probably going to invoke the API directly to copy dashboard objects around, but it would be nice if security_tenant was an option on the resource, or the provider instantiation, or something.

Do you have any additional context?

Sorry if I'm missing something!

@spacez320 spacez320 added enhancement New feature or request untriaged labels Oct 11, 2023
@peterzhuamazon
Copy link
Member

@spacez320
Copy link
Author

@peterzhuamazon It looks like #104 does cover this request. Happy to have this be closed and follow that, instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants