Open Stack

On Fri, Oct 18, 2013 at 11:30:48AM -0400, Sean Dague wrote:
> On 10/17/2013 08:12 AM, Petr Blaho wrote:
> > Hi all,
> >
> > this is probably 3rd or 4th time in quite short time when we were bitten
> > by new version of some out dependencies.
> >
> > Last one (https://review.openstack.org/#/c/52327/3) was about WSME
> > released version 0.5b6 and our tests fail.
> >
> > I do not want to argue if problem is on tuskar side (probably tuskar is
> > to blame according to what jistr found out) or WSME but I think
> > we should discuss possibility of freezing versions in our dependencies
> > definitions and once in a time check for new versions of deps and do
> > update as a separate task.
> >
> > Current state of having open version constraints like WSME<=0.5b5 leads
> > to occasional (or as I see quite frequent) jenkins job failures (as jenkins
> > use clean venv for instalation - devs can have older one so they can
> > miss failure with new version of dep) and these "sudden" failures force
> > us to investigate and divert from planned tasks etc...
> >
> > I think that having regular "update deps" task can lead to better time
> > management and having less "sudden" jenkins failures will be benefical
> > to developers' health :-)
> >
> > Please, tell me if I am missing some obvious problem with freezing dep
> > versions and/or regular update task and if I miss a good side of these
> > "sudden version strikes" too.
> 
> Most of this has already been addressed in the thread. There is a huge 
> trade of here, freezing requirements in the short term makes everything 
> work, in the long term, it causes huge pain. Just look at SQLA pin at <= 
> 0.7.99, which has gone far too long without getting resolved, and has 
> all the distros carrying patches to work around it (now why none of them 
> have contributed those back.... is another question).
> 
> Getting to a single global requirements list this summer took 3 weeks of 
> cross team coordination, because of pinning. Having to unwind 
> coordinated patches like that is lots of fun, let me tell you. :) And 
> while the result isn't perfect, it's so much better than the random gate 
> wedges we were regularly getting that were actually unsolvable through 
> normal process fixes.
> 
> If you are a project with tempest integration, then you actually get a 
> code voice in global requirements bumps, because a g-r change can't land 
> without passing tempest / devstack tests. So integrated projects take 
> note, there are lots of reasons you want to have good tempest tests, and 
> protecting yourself from requirements changes is one of those (wouldn't 
> help in the tuscar case, as that's only got unit tests).
> 
> So, I think we largely need to just take our lumps realizing that we 
> don't have tight control over the python world, and it's better to react 
> quickly, then to hide behind a pin, and not realize that we're massively 
> broken with the latest versions of libraries out there.
> 
> That being said, because WSME is in stackforge, I think we could 
> actually do better than just take our lumps. But I think that's for 
> discussing at the requirements session at summit.
> 
> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Thank you all for responses as these helped me to understand this topic
more.

I am glad I now know about strugle with frozen deps w/r/t packaging to
distros.

-- 
Petr Blaho, pblaho at redhat.com
Software Engineer