Open Stack

On Thu, Aug 03, 2017 at 04:26:12PM +0000, Dave McCowan (dmccowan) wrote:
> 
> 
> On 8/1/17, 8:02 PM, "Tony Breeds" <tony at bakeyournoodle.com> wrote:
> 
> >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
> >openstack/castellan                           []
> >openstack/cinder                              [tc:approved-release]
> >openstack/compute-hyperv                      []
> >openstack/heat                                [tc:approved-release]
> >openstack/kolla                               []
> >openstack/magnum                              []
> >openstack/mistral                             []
> >openstack/neutron-lbaas                       []
> >openstack/neutron-lbaas-dashboard             []
> >openstack/nova                                [tc:approved-release]
> >openstack/octavia                             []
> >openstack/octavia-dashboard                   []
> >openstack/openstackclient                     []
> >openstack/python-openstackclient              []
> >openstack/solum                               []
> >openstack/tacker                              []
> >
> >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
> >--no-merges 4.4.0^..HEAD
> >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
> >work.
> >
> >> 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?
> 
> I'm feeling good with the testing now done on 4.5.2 and would prefer to
> make that the Pike release.  If we were to revert to 4.4.0 for Pike, we
> would be missing at least one feature and the doc changes that were
> planned for Pike.

Not revert, stick with.  We're still using 4.4.0 on master and pike as
all the 4.5.x releases have been broken.

The docs changes could easily be backported to pike with close to zero
risk without a release needed before pike is released it can easily be
done as a zero-day release.

This is all a little moot as 4.5.2 is out and we're testing it.  The
projects in the first will have a g-r update coming before they can
create RC1 and pike branches.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170804/687ed250/attachment.sig>