per project requirements

[Matthew Thode]

Things requirements needs to do before projects can be independent

1. make sure everything in g-r.txt has an existing installable lower version bound specified
1.1. so that valid lower-constraints can be generated just by parsing g-r.txt
1.2. doesn't require looking up stuff on pypi

2. Add a voting check job for ensuring that the lower bounds in g-r are existing and installable to g-r openstack_requirements needs to be released with the necessary tooling to generate a locally valid lower-constraints.txt file based on *-requirements.txt
2.1. * Will be used for g-r self-gating as well as projects lower-constraints maintenance

Things a project needs to do to be independent

1. Make sure project has lower-constraints.txt generated from project's requirements.txt via tool from requirements project
2. Have a voting gate jobs (unit, functional) that tests lower-constraints.txt

check-requirements bot changes
Things requirements needs to do
1. check-requirements needs to be able to check if a project is independent (via list)
2. If project is independent make sure project's requirements.txt allows lower-constraints.txt to be installed else use existing behavior

Things a project needs to do
1. Be independent and verified/added to list requirements maintains

[Matthew Thode (prometheanfire)]

So far we've completed step 1, (we've added lower-bounds to all requirements and have our check job verify such).

Next we need a co-availability (NOT installability) test for generated lower-constraints.txt. This means we will need a script to be extended to generate a lower-constraints.txt file and parse it line by line to check availability. This same script will be used by projects wishing per-project requirements.

Once that step is done we can start working with swift on getting them 'per-project'.

[Matthew Thode (prometheanfire)]

1 we need the script to generate the lower-constraints.txt ( https://review.openstack.org/518416 )
1.1 will take gr lower bounds and apply them as a constraint, overwriting the constraint listed in upper-constraints
2 use the generated lower-constraints.txt file and ensure that every package is individually available. via pypi json api.
2.1 We do not care about the co-installability of global lower-constraints.

Project needs a voting gate job that does the following.

1 generate a lower-requirements file from the projects requirements.txt.
1.1 it will convert >= values to === values
2 take that lower-requirements.txt file and install it
2.1 pip freeze and that becomes the lower-constraints.txt and is saved/updated.

Project needs a separate job that uses the lower-constraints.txt and runs the project's tests

[Doug Hellmann (doug-hellmann)]

I'm not sure I follow the stuff about testing availability of lower bounds globally. There shouldn't *be* a global lower bound when we are done. That's part of the point of the project to stop syncing requirements as originally described in https://etherpad.openstack.org/p/ocata-requirements-notes

[Doug Hellmann (doug-hellmann)]

See http://lists.openstack.org/pipermail/openstack-dev/2018-January/126144.html for a concrete reason for doing this.

[Doug Hellmann (doug-hellmann)]

See https://etherpad.openstack.org/p/ocata-requirements-notes for more detailed planning notes.

[Doug Hellmann (doug-hellmann)]

A lot of the work for this was done in the set of patches in https://review.openstack.org/#/q/topic:requirements-stop-syncing