IMHO there's not a clearly great solution here that will work for every deployment configuration. So I think we'll have to choose the least bad option, unfortunately.
Dan and I chatted about this bug today and I will try to summarize what we talked about to try and move things forward. We don't have much time ...
Of the options we have:
1) Redirect all non-service user DELETE /attachments requests to Nova
a) There must be a 'service' role in keystone and it must be assigned to the Nova and Glance users
b) The Cinder service must be configured to enforce service token roles:
[keystone_authtoken]
service_token_roles_required = true
service_token_roles = service (this is the default)
c) The Nova service must be configured to send service tokens:
[service_user]
send_service_user_token = true
(plus username, password, project, etc)
* Consequence of not having the non-default configuration:
There would be a forever loop between Nova and Cinder when Nova attempts any DELETE /attachments calls.
2) Reject all non-service user DELETE /attachments requests
Problems with it:
a-c) Same as option 1)
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected by Cinder until the deployment is configured as required.
3) Do not accept DELETE /attachments requests on the public API endpoint
Problems with it:
a) Nova would need to be configured to call the private API endpoint for DELETE /attachments
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected/ignored by Cinder until the deployment is configured as required.
4) Change default Cinder API policy to admin-only for DELETE /attachments
a) The Nova and Glance users must be configured as admin users
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected/ignored by Cinder until the deployment is configured as required.
5) Other ideas?
Please feel free to correct me if I've got anything wrong here.
Thanks Jeremy.
IMHO there's not a clearly great solution here that will work for every deployment configuration. So I think we'll have to choose the least bad option, unfortunately.
Dan and I chatted about this bug today and I will try to summarize what we talked about to try and move things forward. We don't have much time ...
Of the options we have:
1) Redirect all non-service user DELETE /attachments requests to Nova
Problems with it:
* Requires non-default deployment configuration [1]
a) There must be a 'service' role in keystone and it must be assigned to the Nova and Glance users
b) The Cinder service must be configured to enforce service token roles: authtoken] token_roles_ required = true
[keystone_
service_
service_token_roles = service (this is the default)
c) The Nova service must be configured to send service tokens: user_token = true
[service_user]
send_service_
(plus username, password, project, etc)
* Consequence of not having the non-default configuration:
There would be a forever loop between Nova and Cinder when Nova attempts any DELETE /attachments calls.
2) Reject all non-service user DELETE /attachments requests
Problems with it:
a-c) Same as option 1)
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected by Cinder until the deployment is configured as required.
3) Do not accept DELETE /attachments requests on the public API endpoint
Problems with it:
a) Nova would need to be configured to call the private API endpoint for DELETE /attachments
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected/ignored by Cinder until the deployment is configured as required.
4) Change default Cinder API policy to admin-only for DELETE /attachments
a) The Nova and Glance users must be configured as admin users
* Consequence of not having the non-default configuration:
All DELETE /attachments requests will be rejected/ignored by Cinder until the deployment is configured as required.
5) Other ideas?
Please feel free to correct me if I've got anything wrong here.
[1] https:/ /docs.openstack .org/keystone/ latest/ admin/manage- services. html#service- users