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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
