[openstack-dev] [TripleO][keystone] Pt. 2 of Passing along some field feedback
Lance Bragstad
lbragstad at gmail.com
Wed Jun 28 19:47:55 UTC 2017
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.
[0] https://review.openstack.org/#/c/427872/19
[1] https://review.openstack.org/#/c/428454/
>
> Thanks,
> Kevin
> ________________________________________
> From: Ben Nemec [openstack at nemebean.com]
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170628/6cdf81ec/attachment.sig>
More information about the OpenStack-dev
mailing list