You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The provider is configured with an OrgManager that has the username 540d4f62-7b33-4fb4-a25c-1a112754c004.
This OrgManager creates a space resource and will then set up other resources inside it. Between the two it will need to give itself the SpaceDeveloper role on the space resource via a cloudfoundry_space_users resource.
Here's code illustrating the problem:
locals {
org_deployer=data.cloudfoundry_user.myuser.id
}
resource"cloudfoundry_space""space" {
name=var.nameorg=data.cloudfoundry_org.org.id
}
resource"cloudfoundry_space_users""space_permissions" {
space=cloudfoundry_space.space.iddevelopers=[
# The deployer includes itself as a SpaceDeveloper for each space it creates# so that it can manage resources inside it.# var.cf_user # <<<--- gets added as (client) (unexpected/wrong!)local.org_deployer, # <<<--- gets added as (uaa) (works)"[email protected]",
]
}
data"cloudfoundry_org""org" {
name=var.cf_org_name
}
data"cloudfoundry_user""myuser" {
name=var.cf_userorg_id=data.cloudfoundry_org.org.id
}
If we include the OrgManager username in the list of users to be given roles in a space directly, it will be added as a (client) rather than (uaa), which isn't what we want... The provider won't be able to do subsequent operations in the space like set up services in other resources! However, if we look up the user explicitly and put their id in the list, then they are added as (uaa).
Bug report:
The provider is configured with an OrgManager that has the username
540d4f62-7b33-4fb4-a25c-1a112754c004
.This OrgManager creates a space resource and will then set up other resources inside it. Between the two it will need to give itself the SpaceDeveloper role on the space resource via a
cloudfoundry_space_users
resource.Here's code illustrating the problem:
If we include the OrgManager username in the list of users to be given roles in a space directly, it will be added as a
(client)
rather than(uaa)
, which isn't what we want... The provider won't be able to do subsequent operations in the space like set up services in other resources! However, if we look up the user explicitly and put their id in the list, then they are added as(uaa)
.(Note: The name may match a client GUID (or at least a regexp for one), but as an OrgManager myself I don't know... Our platform generates the username using a broker.)
The text was updated successfully, but these errors were encountered: