Open Stack

On 02/24/2017 07:09 AM, 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...
> 

It sounds like you want to approve of updates being done to specific
packages in upper-constraints.txt.  We generally don't do this because
with the amount of packages held in upper-constraints it'd become
unmanageable to have 'owners' for each package (or even just some of
them).  We do cross test updates though, if updates to zhmcclient
continually cause downstream projects to fail then there may be a case
to be made in adding the dowstream project to our cross-project gating.

As to your desire to cap/change/lock-down your requirements.txt
downstream projects that consume the requirements project are required
to be in sync with our constraints.  Also, all projects using
upper-constraints.txt to test means that we ensure all of those projects
are co-installable.

Our current policy for updating upper-constraints.txt is to require the
bot to do it unless also updating global-requirements.txt.  This is the
reduce conflicts that could be introduced between the bot updates and
on-off uc.txt changes.  Perhaps a policy change is needed?  If so, we'd
also have to change the daily bot update to submit one change at a time
to help reduce conflicts.

> 
> 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...)
> 
> But the same question like above, can I control the upper constraints in
> my project?
> 

Your project doesn't have an upper-constraints file, but a
(test-)requirements.txt file.  Projects test via upper-constraints.txt
in order to ensure co-installability.  So altering your requirements
would bring you out of sync with the rest of openstack (and we'd have to
remove you from gr-updates eventually as well).

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

If you have more questions about requirements and your project don't
hesitate to ask, we are in #openstack-requirements as well.

-- 
Matthew Thode (prometheanfire)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170224/c72b914f/attachment.pgp>