On Tue, Mar 29, 2016 at 6:18 PM, Adam Young <[email protected]> wrote: > 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 keystone::policy (and generally neutron::policy, nova::policy, etc...) class is pretty robust: * it creates news policies or update existing ones. * it does not delete old policies, that are already in the file. * notify keystone service on every change. Please use it and let us know if we need to change something in puppet-keystone, that would help you to deploy the use-case. > > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
