[requirements][heat] remove salt from requirements (used by heat-agents tests only)
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 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. Is the heat team ok with this? -- Matthew Thode
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.
On 19-10-08 17:22:34, Zane Bitter wrote:
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.
Ya, I remember that conversation :D If it helps I think we can sidestep this as the tests are currenly not using salt managed by requirements. Also, salt will not be updated while they are capping pyyaml. IIRC there was a way to tell the package installer a version you wanted. -- Matthew Thode
participants (2)
-
Matthew Thode
-
Zane Bitter