Packaging ansible-core aka ansible > 2.9: How to package, where to submit to, ...
TL;DR: - Package ansible-core in addition to ansible 2.9? - Where to submit to? systemsmanagement or a subproject for "all things ansible"? - Who can help getting the %checks working? Long version: Dear Lars, dear all, I have a lot of ansible related things at work at the moment, so I took a look at the openSUSE ansible package and was wondering why it was still at 2.9. While upstream is at 2.12. Or rather, the newly designed and re-structure ansible-core is at 2.12. Which I did not find for openSUSE. Which is needed for newer versions of ansible-lint (hence it fails to build at the moment). So, I tried to package it and got it building:
https://build.opensuse.org/project/show/home:ojkastl_buildservice:Branch_sys...
(ansible-lint-5.4 built fine yesterday, apparently some pytest update broke the checks...) Caveats: - I only targeted Tumbleweed and ignored everything else, to just get it building - I had to disable most of the %check sections as the tests were failing out of the box and I had no time and no desire to dig into that - I kept the ansible-core spec file as short as possible, i.e. I ignored all the RHEL/Fedora/... related things that are present in the I tested the packages on a Tumbleweed VM and could successfully install ansible-base (the 2.10 version) or ansible-core. I added Conflicts to the spec so you can only install one of ansible, ansible-core or ansible-base, while all three of them "Provide" ansible. I could also install the 6.0.x version of ansible-lint and linted a small role (with the desired effect, finding things that the 5.4 version did not find/complain about). So, how should I proceed? 1. I am not sure if packaging only ansible-core (aka updating the ansible package to contain ansible-core) would create problems for users that are not aware of the changes (many modules were removed and are now available as collections via the Ansible Galaxy). Should we package ansible-core separately in addition to ansible 2.9? 2. Where to submit the packages to? Would it make sense to move all things related to ansible to a subproject of systemsmanagement? I guess the python-* dependencies could go to dlp* somewhere (not sure what the current layout is for python things, lost track ...) and could be maintained there. 3. Who could take a look at the packages and help in getting them nice and shiny? Especially the %check sections need a lot of love from someone more knowledgeable than me :-) 4. Not sure if it is worth the effort to try to package this for older distributions, e,g, Leap 15.3 / 15.4 or other distros like CentOS. The systemsmanagement project has a lot of build targets. :-) I can try to drive this and help as much as I can, but I would be glad for help and feedback (packaging guidelines that I missed, etc.). Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Dear Johannes, Thank you for your efforts! On 4/25/22 9:12 PM, Johannes Kastl wrote:
2. Where to submit the packages to? Would it make sense to move all things related to ansible to a subproject of systemsmanagement? I guess the python-* dependencies could go to dlp* somewhere (not sure what the current layout is for python things, lost track ...) and could be maintained there.
My understanding of dlp is, that it was meant for packages related to developing python and is not a haven for all python-related stuff which is not placed elsewhere. But if the packages about are actually ansible (python-ansible-* and python-antsibull*), that does not prevent them from being maintained in systemsmanagement along with the other ansible-related packages. Otherwise we have split responsibilities and also troubles when coordinated updates of these packages are needed. python-Twiggy, python-perky and python-asyncio-pool look generic and I'd place them in dlp, too.
4. Not sure if it is worth the effort to try to package this for older distributions, e,g, Leap 15.3 / 15.4 or other distros like CentOS. The systemsmanagement project has a lot of build targets. :-)
CentOS & derivatives have ansible in official repos, so I wouldn't bother. Leap 15.4 could be interesting, but not as top priority. P.S.: I've already sent you a request with some fixes on the python packages. Sebastian
Hi Sebastian, On 25.04.22 at 21:49 Sebix wrote:
On 4/25/22 9:12 PM, Johannes Kastl wrote:
2. Where to submit the packages to? Would it make sense to move all things related to ansible to a subproject of systemsmanagement? I guess the python-* dependencies could go to dlp* somewhere (not sure what the current layout is for python things, lost track ...) and could be maintained there.
My understanding of dlp is, that it was meant for packages related to developing python and is not a haven for all python-related stuff which is not placed elsewhere. But if the packages about are actually ansible (python-ansible-* and python-antsibull*), that does not prevent them from being maintained in systemsmanagement along with the other ansible-related packages. Otherwise we have split responsibilities and also troubles when coordinated updates of these packages are needed.
python-Twiggy, python-perky and python-asyncio-pool look generic and I'd place them in dlp, too.
I think that is a good summary, so unless someone objects I would to that once we are done.
CentOS & derivatives have ansible in official repos, so I wouldn't bother. Leap 15.4 could be interesting, but not as top priority.
I will take a look if I can get it building for Leap 15.4 and SLES15.4 without too much effort, as I will need it on those anyway. But that would be something for a second step, after getting it into Factory.
P.S.: I've already sent you a request with some fixes on the python packages.
Thank you very much, I also saw that Ben sent a SR. I'll check them tomorrow. Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 26.04.22 um 16:27 schrieb Johannes Kastl:
CentOS & derivatives have ansible in official repos, so I wouldn't bother. Leap 15.4 could be interesting, but not as top priority.
I will take a look if I can get it building for Leap 15.4 and SLES15.4 without too much effort, as I will need it on those anyway. But that would be something for a second step, after getting it into Factory.
ansible-core says it requires Python >= 3.8. Forget SLE/Leap 15.
Hi Benjamin, On 26.04.22 at 16:42 Ben Greiner wrote:
Am 26.04.22 um 16:27 schrieb Johannes Kastl:
I will take a look if I can get it building for Leap 15.4 and SLES15.4 without too much effort, as I will need it on those anyway. But that would be something for a second step, after getting it into Factory.
ansible-core says it requires Python >= 3.8. Forget SLE/Leap 15.
You are right, unfortunately. But at least ansible-base aka ansible 2.10 is building fine for Leap 15.4... :-( Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 26.04.22 um 22:18 schrieb Johannes Kastl:
Hi Benjamin,
On 26.04.22 at 16:42 Ben Greiner wrote:
Am 26.04.22 um 16:27 schrieb Johannes Kastl:
I will take a look if I can get it building for Leap 15.4 and SLES15.4 without too much effort, as I will need it on those anyway. But that would be something for a second step, after getting it into Factory.
ansible-core says it requires Python >= 3.8. Forget SLE/Leap 15.
You are right, unfortunately.
But at least ansible-base aka ansible 2.10 is building fine for Leap 15.4... :-(
It installs. That's just copying around some python scripts. It does not mean that it works when it's executed. This is why we strongly encourage to execute the unit tests in %check. - Ben.
Johannes
Hi Benjamin, On 26.04.22 at 22:25 Ben Greiner wrote:
But at least ansible-base aka ansible 2.10 is building fine for Leap 15.4... :-(
It installs. That's just copying around some python scripts. It does not mean that it works when it's executed. This is why we strongly encourage to execute the unit tests in %check.
Sure, the final goal is to get a working executable. At least ansible-base does not require python >= 3.8, so it at least builds for 15.4. Speaking of checks, I accepted your SR for ansible-core and saw that you added a (commented) %checks section. However this always fails, no matter what I tried. Did it work for you? Kind Regards, Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Am 26.04.22 um 22:31 schrieb Johannes Kastl:
Hi Benjamin,
On 26.04.22 at 22:25 Ben Greiner wrote:
But at least ansible-base aka ansible 2.10 is building fine for Leap 15.4... :-(
It installs. That's just copying around some python scripts. It does not mean that it works when it's executed. This is why we strongly encourage to execute the unit tests in %check.
Sure, the final goal is to get a working executable. At least ansible-base does not require python >= 3.8, so it at least builds for 15.4.
Speaking of checks, I accepted your SR for ansible-core and saw that you added a (commented) %checks section. However this always fails, no matter what I tried. Did it work for you?
No I didn't. Just now. [ 23s] Initializing "/tmp/ansible-test-mjz3e72_-injector" as the temporary injector directory. [ 23s] Injecting "/tmp/python-2imoylii-ansible/python" as a execv wrapper for the "/usr/bin/python3" interpreter. [ 23s] Run command: pytest --forked -r a -n auto --color no -p no:cacheprovider -c/home/abuild/rpmbuild/BUILD/ansible-core-2.12.4/test/lib/ansible_test/_data/pytest.ini --junit-xml /home/abuild/rpmbuild/BUILD/ansible-core-2.12.4/test/results/junit/python3.8-modules-units.xml --durations=25 --strict-markers -v test/units/modules/test_apt.py test/units/modules/test_apt_key.py test/units/modules/test_async_wrapper.py test/units/modules/test_copy.py test/units/modules/test_hostname.py test/units/modules/test_iptables.py test/units/modules/test_known_hosts.py test/units/modules/test_pip.py test/units/modules/test_service.py test/units/modules/test_service_facts.py test/units/modules/test_systemd.py test/units/modules/test_unarchive.py test/units/modules/test_yum.py [ 23s] ERROR: usage: __main__.py [options] [file_or_dir] [file_or_dir] [...] [ 23s] __main__.py: error: unrecognized arguments: --forked -n test/units/modules/test_apt.py test/units/modules/test_apt_key.py test/units/modules/test_async_wrapper.py test/units/modules/test_copy.py test/units/modules/test_hostname.py test/units/modules/test_iptables.py test/units/modules/test_known_hosts.py test/units/modules/test_pip.py test/units/modules/test_service.py test/units/modules/test_service_facts.py test/units/modules/test_systemd.py test/units/modules/test_unarchive.py test/units/modules/test_yum.py [ 23s] inifile:/home/abuild/rpmbuild/BUILD/ansible-core-2.12.4/test/lib/ansible_test/_data/pytest.ini [ 23s] rootdir: /home/abuild/rpmbuild/BUILD/ansible-core-2.12.4/test/units/modules Seems like you are missing python3-pytest-forked and python3-pytest-xdist. Check the test-dependencies. The CI setup on their github repo might be a good start.
Kind Regards, Johannes
- Ben
On 26.04.22 at 22:40 Ben Greiner wrote:
Am 26.04.22 um 22:31 schrieb Johannes Kastl:
Speaking of checks, I accepted your SR for ansible-core and saw that you added a (commented) %checks section. However this always fails, no matter what I tried. Did it work for you?
Seems like you are missing python3-pytest-forked and python3-pytest-xdist. Check the test-dependencies. The CI setup on their github repo might be a good start.
Thanks, I'll have a look! Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hi all, On 25.04.22 at 21:12 Johannes Kastl wrote:
TL;DR:
- Where to submit to? systemsmanagement or a subproject for "all things ansible"?
I finally got some time to proceed here. I would like to raise the question again whether it would make sense to create systemsmanagement:ansible and put everything related to ansible into this subproject. As there are quite some dependencies needed it might make sense to not clutter up systemsmanagement anymore. Kind Regards Johannes P.S.:
- Package ansible-core in addition to ansible 2.9? Any opinions here?
-- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (3)
-
Ben Greiner -
Johannes Kastl -
Sebix