On 07/04/2017 12:58 PM, Emilien Macchi wrote:
On Wed, Jun 28, 2017 at 3:47 PM, Lance Bragstad <[email protected]> wrote:
On 06/28/2017 02:29 PM, Fox, Kevin M wrote:
I think everyone would benefit from a read-only role for keystone out of the
box. Can we get this into keystone rather then in the various distro's?
Yeah - I think that would be an awesome idea. John Garbutt had some good
work on this earlier in the cycle. Most of it was documented in specs
[0] [1]. FWIW - this will be another policy change that is going to have
cross-project effects. It's implementation or impact won't be isolated
to keystone if we want read-only roles out-of-the-box.
I just wanted to complete what Lance said with the ongoing
cross-project effort: we're close to approve
https://review.openstack.org/#/c/469954/ for Queens cycle, which means
projects would make some efforts on moving default policies into code
and documenting them.
Oh, that reminds me that the policy-in-code stuff came up on one of
these calls too (since I first wrote the emails). There was definitely
a desire from the people on the call to have all the projects taking
advantage of policy-in-code for the sake of consistency across all the
OpenStack projects. Otherwise it gets confusing to know whether you
need a full policy file or just overrides.
I also think it would be great to solve this issue into projects
themselves and provide the option for operators.
The way it was done in TripleO (manage policy.json files with Puppet)
was temporary I guess, until we can use what will be done by projects.
Any feedback to make it better in the meanwhile is very welcome.
[0] https://review.openstack.org/#/c/427872/19
[1] https://review.openstack.org/#/c/428454/
Thanks,
Kevin
________________________________________
From: Ben Nemec [[email protected]]
Sent: Wednesday, June 28, 2017 12:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [TripleO] Pt. 2 of Passing along some field feedback
A few weeks later than I had planned, but here's the other half of the
field feedback I mentioned in my previous email:
* They very emphatically want in-place upgrades to work when moving from
non-containerized to containerized. I think this is already the plan,
but I told them I'd make sure development was aware of the desire.
* There was also great interest in contributing back some of the custom
templates that they've had to write to get advanced features working in
the field. Here again we recommended that they start with an RFE so
things could be triaged appropriately. I'm hoping we can find some
developer time to help polish and shepherd these things through the
review process.
* Policy configuration was discussed, and I pointed them at some recent
work we have done around that:
https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/api_policies.html
I'm not sure it fully addressed their issues, but I suggested they
take a closer look and provide feedback on any ways it doesn't meet
their needs.
The specific use case they were looking at right now was adding a
read-only role. They did provide me with a repo containing their
initial work, but unfortunately it's private to Red Hat so I can't share
it here.
* They wanted to be able to maintain separate role files instead of one
monolithic roles_data.yaml. Apparently they have a pre-deploy script
now that essentially concatenates some individual files to get this
functionality. I think this has already been addressed by
https://review.openstack.org/#/c/445687
* They've also been looking at ways to reorganize the templates in a
more intuitive fashion. At first glance the changes seemed reasonable,
but they were still just defining the layout. I don't know that they've
actually tried to use the reorganized templates yet and given the number
of relative paths in tht I suspect it may be a bigger headache than they
expect, but I thought it was interesting. There may at least be
elements of this work that we can use to make the templates easier to
understand for deployers.
Thanks.
-Ben
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
