[openstack-dev] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library
tony at bakeyournoodle.com
Wed Aug 2 00:02:32 UTC 2017
On Tue, Aug 01, 2017 at 04:58:22PM -0400, Doug Hellmann wrote:
> Excerpts from Dave McCowan (dmccowan)'s message of 2017-08-01 20:48:12 +0000:
> > This note is to request a Feature Freeze Exemption (FFE) for the python-barbicanclient library in Pike.
> > Python-barbicanclient 4.5.0 was intended to be the Pike release. However, after it was released, testing with the Heat and Octavia projects found that it contained an incompatible change resulting in Tracebacks for those projects.
> > The issue was reported in this bug.
> > https://bugs.launchpad.net/python-barbicanclient/+bug/1706841
> > A first, and partial, attempt to fix this was merged in this patch.
> > https://review.openstack.org/487721
> > This patch is included in release 4.5.1.
> > A second, and successful, fix was merged in this patch.
> > https://review.openstack.org/489518
> > This patch is included in release 4.5.2.
> > The Barbican team requests a feature freeze exemption for python-barbicanclient release 4.5.2 to be the release for Pike. Releases 4.5.0 and 4.5.1 should be blocked in global requirements.
> > Thanks,
> > Dave
> > IRC:dave-mccowan
> This sounds reasonable. It's a critical problem but only affects a small
> number of projects, so the risk is fairly small.
The current users of python-barbicanclient are:
Package : python-barbicanclient [python-barbicanclient!=4.5.0,>=4.0.0] (used by 16 projects)
Also affects : 16 projects
But IIUC it's really only octavia and heat that don't work with 4.5.x
Looking at the change logs:
[tony at thor python-barbicanclient]$ git log --decorate --oneline
714fce2 (HEAD -> master, origin/master, origin/HEAD, gerrit/master) Support import modules from barbicanclient.client module
49505b9 (tag: 4.5.1) Workaround for importing objects from old path
ea509a5 Update api references according to refactor result
e0e3703 Add secret_type filter to CLI
f844a0e Updated from global requirements
a95c1a1 Update the documentation link for doc migration
51d8bfa Updated from global requirements
c497189 fix default version
3c7d909 Updated from global requirements
e599dfd Update doc references
2479529 import content from cli-reference in openstack-manuals
9af9169 rearrange the existing docs into the new standard layout
4eed5c8 Switch from oslosphinx to openstackdocstheme
439ee25 (tag: 4.4.0) Updated from global requirements
97906c8 Refactor barbicanclient
So all the changes look okay to me, assuming the 4.5.1 and 4.5.2 patches
> I assume you've done enough testing to feel comfortable that 4.5.2 will
> work better than 4.5.0 and 4.5.1?
Once we have the release I'll create no-op changes in all the affected
projects that depend on the u-c bump.
What concerns me a little is that we can't test this without a release
and once we do the release we're committed to some form of g-r
alteration with the impacts associated with it.
Would it be terrible to branch stable/pike @ 4.4.0 and leav all the
4.5.x stuff for queens?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the OpenStack-dev