remote stack fails on autoscaling - redelegation depth

[Tomer Shtilman]

on auto scaling event (via heat-cfn-api) where in the autoscaling group there is a resource of type OS::Heat::Stack we are getting an error "HTTPInternalServerError: ERROR: Remote error: Forbidden Remaining redelegation depth of 0 out of allowed range of [0..3] "
we tried also with the default config and also with the following keystone.conf :
[trust]
allow_redelegation = true
max_redelegation_count = 3
enabled = true

attached logs and example template , we scale out posting to the scaleup url

[Steve Baker (steve-stevebaker)]

Using OS::Heat::Stack is meant to be for stacks which span cloud regions (and one day, span clouds)

If you don't actually need to launch asg on a different region to the one you're currently using, you should use heat's template resource support and just do something like:

  asg:
    type: OS::Heat::AutoScalingGroup
    properties:
      min_size: 1
      max_size: 5
      resource:
        type: stack.yaml

If you really do need to use OS::Heat::Stack, have you tried raising max_redelegation_count to 4? There could be a case for adding keystone to this bug and citing your use case to justify changing the default.

[Tomer Shtilman (tomer-shtilman)]

The actual use case is a multi region setup , we are using the context field of the remote stack to deploy on a different region , our setup consists of two regions.

I have increased the max_redelegation_count up to 9 still had the same error

[Steve Baker (steve-stevebaker)]

Given my comment in bug 1451475 you may end up restructuring your templates in a way which avoids this problem

[Tomer Shtilman (tomer-shtilman)]

I dont see a way to reconstruct the stack using a remote stack ,see my comments on bug 1451475

[Tomer Shtilman (tomer-shtilman)]

there is an way to reconstruct the template in such a way that the scaling group itslef will be a part of the stack in the remote region and will consist of nested stack

[Morgan Fainberg (mdrnstm)]

So that it is clear to me: what is causing the hit to the max re delegation count? Is there a number that r solves this issue?

The reason for having a maximum re delegation depth is for performance, the resolution of the re delegation chain gets expensive as the depth goes up. This looks like a legitimate issue showing up at face value, you are redelegating a significant number of times (are you building things up in a way that re delegates via trusts over and over)?

@Steve Baker, if you have any input on this, please feel free to respond as well.

[Morgan Fainberg (mdrnstm)]

When responding please move the bug back to "new" state if this still need to be looked at by Keystone

[Launchpad Janitor (janitor)]

[Expired for Keystone because there has been no activity for 60 days.]