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.

Attachment: signature.asc
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to