Open Stack

On 07/04/2017 12:58 PM, Emilien Macchi wrote:
> On Wed, Jun 28, 2017 at 3:47 PM, Lance Bragstad <lbragstad at gmail.com> 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 [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
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>