Re: [openstack-dev] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Steve Martinelli]

We're more than happy with that outcome, and may have already started the
patch ;) https://review.openstack.org/#/c/370011/

On Wed, Sep 14, 2016 at 5:10 AM, Ihar Hrachyshka 
wrote:

> Steve Martinelli  wrote:
>
> A bug was recently filed against keystone [1]. As of the Newton release we
>> depend on a class being public -- BaseAuthProtocol instead of
>> _BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].
>>
>> The current requirement for keystonemiddleware is:
>>   keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0
>>
>> Blocking 4.0.0 would logically make it:
>>   keystonemiddleware>=4.2.0,!=4.5.0
>>
>> I've pushed a patch to the requirements repo for this change [4]. I'd
>> like to know if blocking the lower value makes sense, I realize it's
>> advertised, but we're up to 4.9.0 now.
>>
>> Unfortunately, many projects depend on keystonemiddleware, but (luckily
>> ?) this should only be server side projects [5], most of which are going
>> through their RC period now.
>>
>
> I suggest instead keystone closes the gap on their side, by falling back
> to _BaseAuthProtocol class if public one is not present. No requirement
> updates, no delay in rc1, just some time for keystone folks to be aware
> that the private class in 4.0.+ series is to be considered kinda public for
> their own usage.
>
> Ihar
>
>
> __
> 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] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Ihar Hrachyshka]

Steve Martinelli  wrote:

A bug was recently filed against keystone [1]. As of the Newton release  
we depend on a class being public -- BaseAuthProtocol instead of  
_BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].


The current requirement for keystonemiddleware is:
  keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0

Blocking 4.0.0 would logically make it:
  keystonemiddleware>=4.2.0,!=4.5.0

I've pushed a patch to the requirements repo for this change [4]. I'd  
like to know if blocking the lower value makes sense, I realize it's  
advertised, but we're up to 4.9.0 now.


Unfortunately, many projects depend on keystonemiddleware, but (luckily  
?) this should only be server side projects [5], most of which are going  
through their RC period now.


I suggest instead keystone closes the gap on their side, by falling back to  
_BaseAuthProtocol class if public one is not present. No requirement  
updates, no delay in rc1, just some time for keystone folks to be aware  
that the private class in 4.0.+ series is to be considered kinda public for  
their own usage.


Ihar

__
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] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Tony Breeds]

On Tue, Sep 13, 2016 at 03:53:46PM -0400, Steve Martinelli wrote:
> A bug was recently filed against keystone [1]. As of the Newton release we
> depend on a class being public -- BaseAuthProtocol instead of
> _BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].
> 
> The current requirement for keystonemiddleware is:
>   keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0
> 
> Blocking 4.0.0 would logically make it:
>   keystonemiddleware>=4.2.0,!=4.5.0
> 
> I've pushed a patch to the requirements repo for this change [4]. I'd like
> to know if blocking the lower value makes sense, I realize it's advertised,
> but we're up to 4.9.0 now.
> 
> Unfortunately, many projects depend on keystonemiddleware, but (luckily ?)
> this should only be server side projects [5], most of which are going
> through their RC period now.

So the *only* reasons we can do this is because no prjects have tagged RC1 and
the only projects that this really impacts are all services:

Package  : keystonemiddleware [keystonemiddleware!=4.1.0,!=4.5.0,>=4.0.0] 
(used by 37 projects)
Included in  : 27 projects
openstack/barbican[type:service]
openstack/cinder  [type:service]
openstack/congress[type:service]
openstack/designate   [type:service]
openstack/freezer-api [type:service]
openstack/glance  [type:service]
openstack/heat[type:service]
openstack/ironic  [type:service]
openstack/karbor  [type:service]
openstack/keystone[type:service]
openstack/magnum  [type:service]
openstack/manila  [type:service]
openstack/mistral [type:service]
openstack/monasca-api [type:service]
openstack/monasca-log-api [type:service]
openstack/murano  [type:service]
openstack/neutron [type:service]
openstack/nova[type:service]
openstack/sahara  [type:service]
openstack/searchlight [type:service]
openstack/senlin  [type:service]
openstack/solum   [type:service]
openstack/tacker  [type:service]
openstack/trove   [type:service]
openstack/vitrage [type:service]
openstack/watcher [type:service]
openstack/zaqar   [type:service]
Also affects : 10 projects
openstack/astara  [release:cycle-with-milestones]
openstack/cue []
openstack/ironic-inspector[release:cycle-with-intermediary]
openstack/kingbird[]
openstack/kosmos  []
openstack/networking-sfc  [release:independent]
openstack/nimble  []
openstack/octavia [release:independent]
openstack/tricircle   []
openstack/zun []

This will means that *all* theose projects need to delay RC1 until they merge
the generated requirements update.  It also adds another thing for the release
managers to check in a tight window.

So I'm inclined to delay this until after we branch stable/newton.

I get that it's wrong to list a minimum we know is broken but I think that's the
less bad option at this point in the cycle.  Packagers/deployers have a pretty
easy solution:  Grab one of the otehr 9 versions:
4.2.0, 4.3.0, 4.4.0, 4.4.1, 4.5.1, 4.6.0, 4.7.0, 4.8.0 or 4.9.0
preferably 4.9.0 as that's what we're testing with.

This will be better in Ocata.

Yours Tony.


signature.asc
Description: PGP 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] [requirements][FFE][keystone][release] block keystonemiddleware 4.0.0

[Matthew Thode]

On 09/13/2016 02:53 PM, Steve Martinelli wrote:
> A bug was recently filed against keystone [1]. As of the Newton release
> we depend on a class being public -- BaseAuthProtocol instead of
> _BaseAuthProtocol [2]. Which was introduced in 4.1.0 [3].
> 
> The current requirement for keystonemiddleware is:
>   keystonemiddleware>=4.0.0,!=4.1.0,!=4.5.0
> 
> Blocking 4.0.0 would logically make it:
>   keystonemiddleware>=4.2.0,!=4.5.0
> 
> I've pushed a patch to the requirements repo for this change [4]. I'd
> like to know if blocking the lower value makes sense, I realize it's
> advertised, but we're up to 4.9.0 now. 
> 
> Unfortunately, many projects depend on keystonemiddleware, but (luckily
> ?) this should only be server side projects [5], most of which are going
> through their RC period now.
> 
> Thanks for reading,
> Steve
> 
> [1] https://bugs.launchpad.net/keystone/+bug/1623091
> [2] 
> https://github.com/openstack/keystone/blob/master/keystone/middleware/auth.py#L38
> [3] 
> https://github.com/openstack/keystonemiddleware/commit/54cba09855fd366875391cbd25c3b3c346ff7a1b
> [4] https://review.openstack.org/#/c/369624/2
> [5] 
> http://codesearch.openstack.org/?q=keystonemiddleware=nope=requirements.txt=
> 
> 
> __
> 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
> 

Nothing in codesearch popped out at me so this looks fine.

-- 
-- Matthew Thode (prometheanfire)



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