[openstack-dev] check-requirements and you

Matthew Thode prometheanfire at gentoo.org
Wed Sep 5 05:12:07 UTC 2018

On 18-09-05 07:04:12, Andreas Jaeger wrote:
> On 2018-09-05 05:20, Matthew Thode wrote:
> > With the move to per-project requirements (aka divergent requirements)
> > we started allowing projects to have differing exclusions and minimums.
> > As long as projects still tested against upper-constraints we were good.
> > 
> > Part of the reason why we use upper-constraints is to ensure that
> > project A and project B are co-installable.  This is especially useful
> > to distro packagers who can then target upper-constraints for any
> > package updates they need.  Another reason is that we (the requirements
> > team) reviews new global-requirements for code quality, licencing and
> > the like, all of which are useful to Openstack as a whole.
> > 
> > If a projects dependencies are compatible with the global list, and the
> > global list is compatible with the upper-constraints, then the
> > projects' dependencies are compatible with the upper-constraints.
> > 
> > All the above lets us all work together and use any lib listed in
> > global-requirements (at the upper-constraints version).  This is all
> > ensured by having the check-requirements job enabled for your project.
> > It helps ensure co-installability, code quality, python version
> > compatibility, etc.  So please make sure that if you are running
> > everything in your own zuul config (not project-config) that you have
> > the check-requirements job as well.
> And also set up and run the lower-constraints jobs - you can use the new
> template openstack-lower-constraints-jobs for this,

Of course!!!

Lower-constraints are useful (again, mainly for packagers, but also to
know the state of our dependencies).  Specifying and testing
lower-constraints means that there's less potential for bugs that are
caused because a project missed the deprecation of some library feature
that they used.  It also means that we have a second set of constraints
(one that's just for that project) that we know works and can be
targeted if needed.  This massively increases the flexibility of
deployments and packaging.

Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180905/e48547e0/attachment.sig>

More information about the OpenStack-dev mailing list