Open Stack

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