Open Stack

On Tue, Mar 29, 2016 at 6:18 PM, Adam Young <ayoung at redhat.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi