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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
