Open Stack

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
> heat-config-salt/install.d/hook-salt.py

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 
constraints: https://review.opendev.org/604386

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.

cheers,
Zane.