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

Reply via email to