Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Lance Bragstad]

I was able to automate some of this report. I figured a follow up
containing data about what was worked on would be nice.


Bug #1703467 in OpenStack Identity (keystone): "assert_admin is checking
default policy rule not admin_required"
https://bugs.launchpad.net/keystone/+bug/1703467
participants: lbragstad, edmondsw
Triaged, tagged, set target milestone, and worked on patch

Bug #1696264 in OpenStack Identity (keystone): "Create OpenStack client
environment scripts in Installation Guide INCOMPLETE - doesn't state
path for file"
https://bugs.launchpad.net/keystone/+bug/1696264
participants: lbragstad, wingwj
Triaged and set target milestone

Bug #1703666 in OpenStack Identity (keystone): "Templated catalog does
not handle multi-regions properly"
https://bugs.launchpad.net/keystone/+bug/1703666
participants: lbragstad, eandersson
Triaged, set target milestone, discussed alternatives, and worked on a patch

Bug #1133435 in OpenStack Identity (keystone): "policy should return a
400 if a required field is missing"
https://bugs.launchpad.net/keystone/+bug/1133435
participants: lbragstad, edmondsw
Set status, discussed, and proposed  a possible solution due to the work
with policy in code

Bug #1689468 in OpenStack Identity (keystone): "odd keystone behavior
when X-Auth-Token ends with carriage return"
https://bugs.launchpad.net/keystone/+bug/1689468
participants: gagehugo, kaerie
Reproposed patch in review

Bug #1703369 in OpenStack Identity (keystone): "get_identity_providers
policy should be singular"
https://bugs.launchpad.net/keystone/+bug/1703369
participants: lbragstad, edmondsw
Set priority, target to series, set target milestone, proposed and
reviewed patch, discussed backport procedure

Bug #1703438 in keystoneauth: "Discover.version_data: Empty max_version
results in max_microversion=None even if version is specified"
https://bugs.launchpad.net/keystoneauth/+bug/1703438
participants: efried, mordred, morgan
Merged fix

Bug #1703447 in keystoneauth: "URL caching in
EndpointData._run_discovery is busted"
https://bugs.launchpad.net/keystoneauth/+bug/1703447
participants: efried, morgan
Merged fix

Bug #1689468 in keystonemiddleware: "odd keystone behavior when
X-Auth-Token ends with carriage return"
https://bugs.launchpad.net/keystonemiddleware/+bug/1689468
participants: gagehugo, kaerie
Reproposed patch in review


For what it's worth, I also apparently thought office hours occurred on
the 7th when it was actually on the 11th. 



On 07/11/2017 08:35 PM, Lance Bragstad wrote:
>
> Hey all,
>
> This is a summary of what was worked on today during office hours.
> Full logs of the meeting can be found below:
>
> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html
>
> *The future of the templated catalog backend
> *
>
> Some issues were uncovered, or just resurfaced, with the templated
> catalog backend. The net of the discussion boiled down to - do we fix
> it or remove it? The answer actually ended up being both. It was
> determined that instead of trying to maintain and fix the existing
> templated backend, we should deprecate it for removal [0]. Since it
> does provide some value, it was suggested that we can start
> implementing a new backend based on YAML to fill the purpose instead.
> The advantage here is that the approach is directed towards a specific
> format (YAML). This should hopefully make things easier for both
> developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
>
> *Policy fixes*
>
> All the policy-in-code work has exposed several issues with policy
> defaults in keystone. We spent time as a group going through several
> of the bugs [0] [1] [2] [3], the corresponding fixes, and impact. One
> of which will be backported specifically for the importance of
> communicating a release note to stable users [0].
>
> [0] https://bugs.launchpad.net/keystone/+bug/1703369
> [1] https://bugs.launchpad.net/keystone/+bug/1703392
> [2] https://bugs.launchpad.net/keystone/+bug/1703467
> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>
> *Additional bugs worked*
>
> Transient bug with security compliance or PCI-DSS:
> https://bugs.launchpad.net/keystone/+bug/1702211
> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>
>
> I hope to find ways to automate most of what is communicated in this
> summary. Until then I'm happy to hear feedback if you find the report
> lacking in a specific area.
>
>
> Thanks,
>
> Lance
>



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Mathieu Gagné]

Resending... I found out that Gmail messed up my message with its HTML format...
Hopefully this time it will be more readable on the online archive interface.

On Tue, Jul 11, 2017 at 10:28 PM, Mathieu Gagné  wrote:
> Hi,
>
> So this email is relevant to my interests as an operator. =)
>
> On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad  wrote:
>>
>> The future of the templated catalog backend
>>
>> Some issues were uncovered, or just resurfaced, with the templated catalog
>> backend. The net of the discussion boiled down to - do we fix it or remove
>> it? The answer actually ended up being both. It was determined that instead
>> of trying to maintain and fix the existing templated backend, we should
>> deprecate it for removal [0]. Since it does provide some value, it was
>> suggested that we can start implementing a new backend based on YAML to fill
>> the purpose instead. The advantage here is that the approach is directed
>> towards a specific format (YAML). This should hopefully make things easier
>> for both developers and users.
>>
>> [0] https://review.openstack.org/#/c/482714/
>
>
> We have been exclusively using the templated catalog backend for at least 5
> years without any major issues. And it looks like we are now among the < 3%
> using templated according to the April 2017 user survey.
> ¯\_(ツ)_/¯
>
> We choose the templated catalog backend for its simplicity (especially with
> our CMS) and because it makes no sense (to me) to use and rely on an
> SQL server to serve what is essentially static content.
>
> Regarding the v3 catalog support, we do have an in-house fix we intended to
> upstream very soon (and just did right now). [1]
>
> So if the templated catalog backend gets deprecated,
> my wish would be to have access to an alternate file based
> implementation, a production grade implementation ready to be used
> before I get spammed with deprecation warnings in the keystone logs.
>
> Thanks
>
> [1] https://review.openstack.org/#/c/482766/
>
> --
> Mathieu
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Lance Bragstad]

On 07/12/2017 09:17 AM, Akihiro Motoki wrote:
> 2017-07-12 10:35 GMT+09:00 Lance Bragstad :
>> Hey all,
>>
>> This is a summary of what was worked on today during office hours. Full logs
>> of the meeting can be found below:
>>
>> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html
> It is not specific to keystone.
>
> I think it is better to use keystone-office-hours instead of
> office-hours as a meeting name.
> If we use the same meeting names, we will have office-hours logs of
> multiple projects
> in a same directory in eavesdrop.openstack.org.
>
> Thanks,
> Akihiro

Ah - good point. Thanks for the heads up! I'll be sure to do that for
next week's session.

>> The future of the templated catalog backend
>>
>> Some issues were uncovered, or just resurfaced, with the templated catalog
>> backend. The net of the discussion boiled down to - do we fix it or remove
>> it? The answer actually ended up being both. It was determined that instead
>> of trying to maintain and fix the existing templated backend, we should
>> deprecate it for removal [0]. Since it does provide some value, it was
>> suggested that we can start implementing a new backend based on YAML to fill
>> the purpose instead. The advantage here is that the approach is directed
>> towards a specific format (YAML). This should hopefully make things easier
>> for both developers and users.
>>
>> [0] https://review.openstack.org/#/c/482714/
>>
>> Policy fixes
>>
>> All the policy-in-code work has exposed several issues with policy defaults
>> in keystone. We spent time as a group going through several of the bugs [0]
>> [1] [2] [3], the corresponding fixes, and impact. One of which will be
>> backported specifically for the importance of communicating a release note
>> to stable users [0].
>>
>> [0] https://bugs.launchpad.net/keystone/+bug/1703369
>> [1] https://bugs.launchpad.net/keystone/+bug/1703392
>> [2] https://bugs.launchpad.net/keystone/+bug/1703467
>> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>>
>> Additional bugs worked
>>
>> Transient bug with security compliance or PCI-DSS:
>> https://bugs.launchpad.net/keystone/+bug/1702211
>> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>>
>>
>> I hope to find ways to automate most of what is communicated in this
>> summary. Until then I'm happy to hear feedback if you find the report
>> lacking in a specific area.
>>
>>
>> Thanks,
>>
>> Lance
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Akihiro Motoki]

2017-07-12 10:35 GMT+09:00 Lance Bragstad :
> Hey all,
>
> This is a summary of what was worked on today during office hours. Full logs
> of the meeting can be found below:
>
> http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html

It is not specific to keystone.

I think it is better to use keystone-office-hours instead of
office-hours as a meeting name.
If we use the same meeting names, we will have office-hours logs of
multiple projects
in a same directory in eavesdrop.openstack.org.

Thanks,
Akihiro

>
> The future of the templated catalog backend
>
> Some issues were uncovered, or just resurfaced, with the templated catalog
> backend. The net of the discussion boiled down to - do we fix it or remove
> it? The answer actually ended up being both. It was determined that instead
> of trying to maintain and fix the existing templated backend, we should
> deprecate it for removal [0]. Since it does provide some value, it was
> suggested that we can start implementing a new backend based on YAML to fill
> the purpose instead. The advantage here is that the approach is directed
> towards a specific format (YAML). This should hopefully make things easier
> for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
>
> Policy fixes
>
> All the policy-in-code work has exposed several issues with policy defaults
> in keystone. We spent time as a group going through several of the bugs [0]
> [1] [2] [3], the corresponding fixes, and impact. One of which will be
> backported specifically for the importance of communicating a release note
> to stable users [0].
>
> [0] https://bugs.launchpad.net/keystone/+bug/1703369
> [1] https://bugs.launchpad.net/keystone/+bug/1703392
> [2] https://bugs.launchpad.net/keystone/+bug/1703467
> [3] https://bugs.launchpad.net/keystone/+bug/1133435
>
> Additional bugs worked
>
> Transient bug with security compliance or PCI-DSS:
> https://bugs.launchpad.net/keystone/+bug/1702211
> Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468
>
>
> I hope to find ways to automate most of what is communicated in this
> summary. Until then I'm happy to hear feedback if you find the report
> lacking in a specific area.
>
>
> Thanks,
>
> Lance
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Lance Bragstad]

On 07/11/2017 09:28 PM, Mathieu Gagné wrote:
> Hi,
>
> So this email is relevant to my interests as an operator. =)

Glad to hear it!

>
> On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad  > wrote:
>
> *The future of the templated catalog backend*
>
> Some issues were uncovered, or just resurfaced, with the templated
> catalog backend. The net of the discussion boiled down to - do we
> fix it or remove it? The answer actually ended up being both. It
> was determined that instead of trying to maintain and fix the
> existing templated backend, we should deprecate it for removal
> [0]. Since it does provide some value, it was suggested that we
> can start implementing a new backend based on YAML to fill the
> purpose instead. The advantage here is that the approach is
> directed towards a specific format (YAML). This should hopefully
> make things easier for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/
> ​
>
>
> We have been exclusively using the templated catalog backend for at
> least 5 years without any major issues. And it looks like we are now
> among the < 3% using templated according to the April 2017 user survey. 
> ¯\_(ツ)_/¯
>
> We choose the templated catalog backend for its simplicity (especially
> with our CMS) and because it makes no sense (to me) to use and rely on an 
> SQL server to serve what is essentially static content
> ​.​
>
>
> Regarding the v3 catalog support, we do have an in-house fix we
> intended to upstream
> ​ very soon (and just did right now)​
> . [1]
>
>
> So if the templated catalog backend gets deprecated, 
> ​my wish would be to have access to
>  a
> ​n alternate​
> ​ file based
> ​ implementation​, a production grade implementation
>  ready to be used
> ​ before I get spammed with deprecation warnings in the keystone logs.

I think that is fair. Morgan was working on an implementation yesterday,
but I don't think anything made it to Gerrit. As soon as it does, I'll
be sure to update the thread. Thanks for speaking up!

>
> Thanks
>
> [1] https://review.openstack.org/#/c/482766/
>
> --
> Mathieu
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] office hours report 2017-7-7

[Mathieu Gagné]

Hi,

So this email is relevant to my interests as an operator. =)

On Tue, Jul 11, 2017 at 9:35 PM, Lance Bragstad  wrote:

> *The future of the templated catalog backend*
>
> Some issues were uncovered, or just resurfaced, with the templated catalog
> backend. The net of the discussion boiled down to - do we fix it or remove
> it? The answer actually ended up being both. It was determined that instead
> of trying to maintain and fix the existing templated backend, we should
> deprecate it for removal [0]. Since it does provide some value, it was
> suggested that we can start implementing a new backend based on YAML to
> fill the purpose instead. The advantage here is that the approach is
> directed towards a specific format (YAML). This should hopefully make
> things easier for both developers and users.
>
> [0] https://review.openstack.org/#/c/482714/​
>

We have been exclusively using the templated catalog backend for at least 5
years without any major issues. And it looks like we are now among the < 3%
using templated according to the April 2017 user survey.
¯\_(ツ)_/¯

We choose the templated catalog backend for its simplicity (especially with
our CMS) and because it makes no sense (to me) to use and rely on an
SQL server to serve what is essentially static content
​.​


Regarding the v3 catalog support, we do have an in-house fix we intended to
upstream
​ very soon (and just did right now)​
. [1]


So if the templated catalog backend gets deprecated,
​my wish would be to have access to
 a
​n alternate​
​ file based
​ implementation​, a production grade implementation
 ready to be used
​ before I get spammed with deprecation warnings in the keystone logs.

Thanks

[1] https://review.openstack.org/#/c/482766/

--
Mathieu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] office hours report 2017-7-7

[Lance Bragstad]

Hey all,

This is a summary of what was worked on today during office hours. Full
logs of the meeting can be found below:

http://eavesdrop.openstack.org/meetings/office_hours/2017/office_hours.2017-07-11-19.00.log.html

*The future of the templated catalog backend
*

Some issues were uncovered, or just resurfaced, with the templated
catalog backend. The net of the discussion boiled down to - do we fix it
or remove it? The answer actually ended up being both. It was determined
that instead of trying to maintain and fix the existing templated
backend, we should deprecate it for removal [0]. Since it does provide
some value, it was suggested that we can start implementing a new
backend based on YAML to fill the purpose instead. The advantage here is
that the approach is directed towards a specific format (YAML). This
should hopefully make things easier for both developers and users.

[0] https://review.openstack.org/#/c/482714/

*Policy fixes*

All the policy-in-code work has exposed several issues with policy
defaults in keystone. We spent time as a group going through several of
the bugs [0] [1] [2] [3], the corresponding fixes, and impact. One of
which will be backported specifically for the importance of
communicating a release note to stable users [0].

[0] https://bugs.launchpad.net/keystone/+bug/1703369
[1] https://bugs.launchpad.net/keystone/+bug/1703392
[2] https://bugs.launchpad.net/keystone/+bug/1703467
[3] https://bugs.launchpad.net/keystone/+bug/1133435

*Additional bugs worked*

Transient bug with security compliance or PCI-DSS:
https://bugs.launchpad.net/keystone/+bug/1702211
Request header issues: https://bugs.launchpad.net/keystone/+bug/1689468


I hope to find ways to automate most of what is communicated in this
summary. Until then I'm happy to hear feedback if you find the report
lacking in a specific area.


Thanks,

Lance



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev