[Rdo-list] python-*client packaging

[Dave Allan]

On Fri, May 30, 2014 at 10:06:49AM +0100, Steven Hardy wrote:
> On Thu, May 29, 2014 at 06:04:44PM -0400, Steve Gordon wrote:
> > I guess what I am driving at is that the process of creating a tag in the OpenStack client projects occurs at pretty arbitrary points in time based on the needs of other OpenStack projects that want to set requirements on them rather than anything relating to the needs of downstream distributions such as RDO or RHELOSP. Because no other OpenStack project needed the particular functionality (and fixes) added to python-novaclient in the last three months no new tag was requested nor created. In this case it means we're missing some 84 odd commits made since the 2.17.0 tag was created.
> > 
> > Given this what I'm wondering is if there is any reason we shouldn't move to a model where we rebase the python-*client packages to the latest git commit at each milestone (J-1, J-2, J-3, RC, GA), regardless of the existence of a tag, to ensure we are always picking up the latest changes? 
> 
> The main reason not to do this IMO is that all of the upstream CI testing
> is done against the latest released version from pypi, not the latest
> client code from trunk.
> 
> My experience working on Heat (which uses pretty much all of the
> python-*clients) is that regressions can and quite frequently do happen
> when a new client version is tagged, which implies you're taking a
> significant risk by taking a random bunch of git snapshots instead of a
> release which has been verified by hundreds/thousands of CI runs upstream.

This is the concern I voiced on the Nova call yesterday.  If the
tagged versions are being used in CI, then I feel quite strongly that
we take advantage of that testing and use the tagged versions, not the
current git head at the time we want to package.

Dave

> Here's one example which happened recently and is still not resolved:
> 
> https://bugs.launchpad.net/python-novaclient/+bug/1322183
> 
> Currently if you install latest novaclient from trunk, several heat unit
> tests break, whereas the latest release works fine.
> 
> Part of the value of working with upstream devs to request a new release is
> tagged, is they will hopefully have better visibility of potential blocker
> issues, so the tag should only be applied when there are no known major
> bugs and fixes/features are fully merged (as opposed to cutting a package
> which contains a paritally implemented feature or bugfix, e.g a subset of a
> series of patches have been merged and some are still under review).
> 
> I'd suggest the solution to this problem is just communication with the
> upstream core devs and PTL's - IME most will be quite responsive if you
> ask for a new client release for a valid reason.
> 
> Steve