Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191008/44aa68ce/attachment.sig>