[requirements][heat] remove salt from requirements (used by heat-agents tests only)
On 7/10/19 4:15 PM, Matthew Thode wrote:
> Salt has been harsh to deal with.
> Upstream adding and maintaining caps has caused it to be held back.
> This time it's pyyaml, I'm not going to hold back the version of pyyaml
> for one import of salt.
> In any case, heat-agents uses salt in one location and may not even be
> using the one we define via constraints in any case.
> File: heat-config-salt/install.d/50-heat-config-hook-salt
> Installs salt from package then runs
This is true, in that the repo itself appears in the form of a set of
disk-image-builder elements. (Though it may not necessarily be used this
way - for example in RDO we package the actual agents as RPMs, ignoring
the d-i-b elements.)
> In heat-config-salt/install.d/hook-salt.py is defined the only import of
> salt I can find and likely uses the package version as it's installed
> after tox sets things up.
However, that module is tested in the unit tests (which is why salt
appears in test-requirements.txt).
> Is the heat team ok with this?
We discussed this a little at the time that I added it to global
The issue for us is that we'd like to be able to use a lower-constraints
job. There's a certain library (*cough*paunch) that keeps releasing new
major versions, so it's very helpful to have tests to verify when we
rewrite for the new API whether or not we have to bump the minimum
version. The rest of the requirements tooling seems useful as well, and
given that the team obviously maintains other repos in OpenStack we know
how to use it, and it gives some confidence that we're providing the
right guidance to distros wanting to package this.
That said, nothing in heat-agents necessarily needs to be co-installable
with OpenStack - the agents run on guest machines. So if it's not tied
to the global-requirements any more then that may not be the worst
thing. But IIRC when we last discussed this there was no recommended way
for a project to run in that kind of configuration. If somebody with
more knowledge of the requirements tooling were able to help out with
suggestions then I'd be more than happy to implement them.