Keystone has a policy API, but no one uses it. It allows us to associate a policy file with an endpoint. Upload a json blob, it gets a uuid. Associate the UUID with the endpoint. It could also be associated with a service, and then it is associated with all endpoint for that service unless explicitly overwritten.
Assuming all of the puppet modules for all of the services support managing the policy files, how hard would it be to synchronize between the database and what we distribute to the nodes? Something along the lines of: if I put a file in this directory, I want puppet to use it the next time I do a redeploy, and I also want it uploaded to Keystone and associate with the endpoint? As a start, I want to be able to replace the baseline policy.json file with the cloudsample. We ship both. We have policy.pp in Puppet Keystone for this use case. In tripleO, we could create a parameter that uses would use to configure specific policies. It would be an hash and puppet will manage the policies. This would handle the Keystone case, but we need to customize all of the policy files, for all of the services, for example, to add the is_admin_project check. I'd like to get this mechanism in place before I start that work, so I can easily test changes. The workflow needs to be something like this: Bring up Keystone with Bootstrap. For each service: Fetch its policy file from the RPM location. Upload to Keystone. Set the service-policy association in Keystone. Deploy the service. Copy over the policy file from Keystone. In order to make a change, say to specialize for an endpoint: Upload new policy file to Keystone Set the Endpoint Association for the Policy File run overcloud deploy and sync all of the policy files down again. We don't have to use the Policy API, but we would end up re-implementing some aspect of it. By using the Keystone API, we also provide a way to query "what is the policy for this endpoint?" I don't think this would be a radical departure from what the Rest of OpenStack would do. I can see Kolla using the same approach, or something like it. Feedback, before I write this up as a spec? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
