[Bug] Inconsistent state for elasticstack_kibana_synthetics_private_location space_id

[doom160]

Describe the bug I was testing out the new resource elasticstack_kibana_synthetics_private_location Seems like the elasticstack_fleet_agent_policy.namespace has to match elasticstack_kibana_synthetics_private_location.space_id

if not you will get an error like this

│ When applying changes to module.agent_policies.elasticstack_kibana_synthetics_private_location.main["dev"], provider
│ "provider[\"registry.terraform.io/elastic/elasticstack\"]" produced an unexpected new value: .space_id: was null, but now
│ cty.StringVal("dev").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷

Trying to understand these 2 values should be matching, it throws the same error if you set unset space_id as null because agent_policy namespace would have been "default"

To Reproduce Steps to reproduce the behavior:

Creating a sample code

resource "elasticstack_fleet_agent_policy" "main" {
  for_each        = toset(var.environments)
  name            = each.value
  namespace       = each.value
  description     = each.value

  sys_monitoring  = true
  monitor_logs    = true
  monitor_metrics = true
}

resource "elasticstack_kibana_synthetics_private_location" "main" {
  for_each        = toset(var.environments)
  label           = each.value
  agent_policy_id = elasticstack_fleet_agent_policy.main[each.value].id
  space_id = "default"
  tags            = [each.value]
  geo = {
    lat = 0
    lon = 0
  }
}

Expected behavior My understanding is space_id is a different thing as namespace, so i dont think it should be matching

Versions (please complete the following information):

• OS: mac
• Terraform Version v1.6.4
• Provider version v0.11.6
• Elasticsearch Version 8.12.2

Additional context Add any other context about the problem here.

[tobio]

@biscout42 do you have a chance to take a look at this?

[biscout42]

Let me have a look. Indeed, space_id is a namespace, or space in kibana terminology, but there might be additional restriction by kibana between policy and location (one example - private location has same id as policy).

@doom160 , does it work for you if you set space_id = each.value for private location?

[biscout42]

I have done a test to verify, if I can create private location in other space, than policy and it doesn't work.

https://github.com/biscout42/terraform-provider-elasticstack/commit/ae4cb58a321936c6c5244c691d646cb9cd80e3a3#diff-b0cd8bfc327e1fcc261059402ae2aff82070b9a7ad832fff809cf62fb55a2ce6R365

Let me get in touch with synthetics folks about the details. We might have restrictions to use only policy namespace.

[doom160]

yes it would have work if i set space_id = each.value

i thought the namespace on agent policy refers to the default namespace for index to this convention <type>-<dataset>-<namespace> ? https://www.elastic.co/guide/en/fleet/current/data-streams.html#data-streams-naming-scheme

and space_id im thinking is it the elastic space? i.e. https://www.elastic.co/guide/en/kibana/current/xpack-spaces.html

[biscout42]

Hi @doom160 , thanks for prompt reply. I could see confusion between space_id , space and namespace. I'm sorry, I can't explain all historical reason why it is so. For private locations I used space_id , because it is the way its documented in API, but in fact it is "space" in terms of elastic stack / kibana.

Indeed, in fleet API it is named namespace: https://www.elastic.co/guide/en/fleet/current/fleet-api-docs.html#create-agent-policy-api . That could refer to data stream terminology.

Updated.

Now interesting part about agent policy and private locations. I have got feedback, that private location is bind to the namespace of the agent policy, which refers to data stream namespace. So correct way to configure it for your example would be:

  space_id = elasticstack_fleet_agent_policy.main[each.value].namespace

@tobio , lets sync shortly, might be we could improve documentation or even drop space_id parameter for private location to reduce confusion.