Isn't it just a case of doing OS_TENANT_NAME=the_tenant heat stack-delete <id of stack> ?
If that works then it's trivial to wrap a tiny script which grabs the project from the stack-list -g and switches to the correct scope before making any further request?
But I acknowledge the desire to have full control over the policy file, and I want us to be responsive to operator requirements, I'm just worried about the bug #968696 impact of any such change.
I'll take this bug and look into possible fixes, and start a ML thread to seek guidance from the keystone folks wrt the best-practice way to implement this in terms of default policy rules.
Ok, so in terms of the CLI wrapper:
-bash-4.3$ . ~/devstack/openrc admin admin NAME=RegionOne API_VERSION= 2.0 192.168. 1.17:5000/ v2.0 NAME=admin API_VERSION= 2
-bash-4.3$ env | grep OS_
OS_REGION_
OS_IDENTITY_
OS_PASSWORD=foobar
OS_AUTH_URL=http://
OS_USERNAME=admin
OS_TENANT_
OS_VOLUME_
OS_NO_CACHE=1
Isn't it just a case of doing OS_TENANT_ NAME=the_ tenant heat stack-delete <id of stack> ?
If that works then it's trivial to wrap a tiny script which grabs the project from the stack-list -g and switches to the correct scope before making any further request?
But I acknowledge the desire to have full control over the policy file, and I want us to be responsive to operator requirements, I'm just worried about the bug #968696 impact of any such change.
I'll take this bug and look into possible fixes, and start a ML thread to seek guidance from the keystone folks wrt the best-practice way to implement this in terms of default policy rules.