Open Stack

Thanks all for your feedback. Seeing things much clearer now.

One last thing: How is the requirements bot being triggered?

- For OpenStack libraries by the jenkins job that handles the tag (if
the metadata is provided)?
- for external libraries? Is the a cronjob every 2 weeks or so? Or is it
even daily except during the requirements freeze?

Thanks!


-- 
-----
Andreas 
IRC: andreas_s



On Fr, 2017-02-24 at 11:22 -0500, Tony Breeds wrote:
> 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.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev