Open Stack

Excerpts from Andreas Scheuring's message of 2017-02-24 14:09:33 +0100:
> Hi, I have a couple of questions in regards of how updates of
> requirements are handled and what happens if I release a new version of
> a library. I read along the README [1], but a few points are still
> unclear to me.
> 
> I have the following projects:
> 
> * os-dpm [4]
>   * is a openstack library that gets release when required
>   * release is done manually (creating a tag and pushing it to gerrit)
>   * listed in global requirements & upper constraints
> * zhmcclient [6]
>   * An "external" library that gets released to pypi
>   * listed in global requirements & upper constraints
> * nova-dpm [2] & networking-dpm [3]
>   * are the main projects and therefore not listed in the openstack
> requirements
>   * both specify the os-dpm and zhmcclient in their requirements.txt
>   * both are accepted in the projects.txt to allow the automated sync of
> global requirements
> 
> 
> Now the scenarios are
> 
> A new version of the external library 'zhmcclient' gets released
> ----------------------------------------------------------------
> 
> What to do in order to get this reflected in upper constraints? At first
> I was pushing manual updates to requirements txt, but the latest version
> was pushed in by the OpenStack proposal bot around 10 days after the
> release [4]. What's the right approach here?

Either works. It may be slightly faster if you update the constraint
by hand, though that depends on how the reviews end up being
prioritized. Another benefit of updating one constraint at a time
is if there is a test failure, it would be easy to debug because
there is only one package.

> How can I ensure that I have to approve a new version for my projects,
> before it gets applied there? (Once it is in upper constraints, it is
> used in my project as well automatically). If I specify an upper
> constraint in my requirements.txt file, then the requirements job
> complains as the requirement does not exactly match the requirementused
> in global requirements...

We run the unit tests (and maybe more?) for a few major projects with a
representative set of the requirements list. We cannot afford to run all
tests for all projects, though.

If you continue to manually patch upper-constraints.txt, then you could
use Depends-On to link any patch in your project to that constraints
change, which should cause the test jobs to run with the new constraint.

> A new version of the openstack library 'os-dpm' gets released
> -------------------------------------------------------------
> 
> As this is an OpenStack project - I think the flow is slightly
> different: If a new release gets tagged with the corresponding metadata,
> a patch to upper constraints is submitted automatically. (I still need
> to figure out how that metdata should look like...)

The scripts that build the metadata are in
openstack-infra/project-config/jenkins/scripts/release-tools. Take
a look at release_from_yaml.sh and release.sh in that directory.
You can run those scripts by hand instead of tagging directly, if
you want.

> But the same question like above, can I control the upper constraints in
> my project?

Not really. The point of upper-constraints is for all projects to
be testing with the same set of packages so we can ensure
co-installability for single-node deployments and so we can clearly
document what we are testing with for distros and other downstream
consumers.

Doug

> 
> 
> Thanks!
> 
> 
> [1] https://github.com/openstack/requirements
> [2] https://github.com/openstack/nova-dpm
> [3] https://github.com/openstack/networking-dpm
> [4] https://github.com/openstack/os-dpm
> [5] https://review.openstack.org/#/c/426487/
> [6] https://github.com/zhmcclient/python-zhmcclient
>