Open Stack

On Fri, Feb 24, 2017 at 02:09:33PM +0100, Andreas Scheuring wrote:
> 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?
> 
> 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...

So if you find that a new version of zhmcclient doesn't work for you the 2
options available to you are:
1) Fix you project to tolerate the new (and old) version
2) Ban (via !=) in openstack/requirements:global-requirements.txt, and revert
   the relevant parts of the upper-constraints.txt change, which will then
   propagate to your project once it merges (via the proposal-bot)

but fundamentally it boils down to we'll accept new versions into
upper-constraints.txt and if it breaks we'll back out/correct it.

If this proves to be overly problematic for you we can discuss ways for you to
more actively engage with requirements management to ensure you can approve
things before that land but that's atypical

> 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...)

Doug's already answer this better than I could.

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

You've opted into having your requirements managed by the requirements team.
So the way to set bans or (if really needed) caps is as I outlined above via
changes to global-requirements.txt.

The management of *constraints* is global and not per-project.

Yours Tony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170224/fe76f908/attachment.pgp>