15:00:33 <mattclay> #startmeeting Ansible Core Public IRC Meeting
15:00:33 <zodbot> Meeting started Thu Nov  5 15:00:33 2020 UTC.
15:00:33 <zodbot> This meeting is logged and archived in a public location.
15:00:33 <zodbot> The chair is mattclay. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:33 <zodbot> The meeting name has been set to 'ansible_core_public_irc_meeting'
15:01:01 <mattclay> #info Agenda: https://github.com/ansible/community/issues/570
15:01:13 <felixfontein> hi
15:01:20 <mattclay> There is nothing on the agenda for today.
15:01:29 <mkrizek> \o
15:01:30 <felixfontein> nice :)
15:01:31 <sdoran> o/
15:01:48 <mattclay> #chair mkrizek sdoran
15:01:48 <zodbot> Current chairs: mattclay mkrizek sdoran
15:02:34 <mattclay> Does anyone have something they'd like to add to the agenda?
15:02:41 <felixfontein> mattclay: is something like https://github.com/ansible/ansible/pull/72430 sensible, and would it even be possible to backport it to say stable-2.9 and stable-2.10?
15:04:53 <mattclay> felixfontein: I'm not sure I understand the issue you're trying to work around. Can you explain more?
15:05:02 <felixfontein> yes :)
15:05:49 <felixfontein> in the community.crypto tests, we install pyOpenSSL and cryptography using the OS package manager for all OS-specfic tests (rhel7, rhel8, ubuntu1604, ubuntu1804, ...)
15:06:20 <felixfontein> but we also want to have OS-independent tests with different Python versions, i.e. with the default container
15:06:32 <felixfontein> but there we must install pyOpenSSL and cryptography with pip
15:06:53 <felixfontein> if we want to run the same tests with both, the tests must somehow know whether to use pip or the OS package manager
15:07:39 <felixfontein> I didn't see any way to specify variables from the outside which could help in this case, and some information on the environment are passed to the tests, but not this one
15:09:30 <felixfontein> does that make sense?
15:09:57 <mattclay> So in this case the issue isn't about detecting the current requirements and OS to determine what to install (and how), but that you have a different intent for how the tests should behave, and you'd like to use the choice of test container to indicate that?
15:10:16 <felixfontein> yes
15:10:42 <felixfontein> the default container is based on Ubuntu IIRC, and thus the tests cannot distinguish simply based on OS, and also not on combination (OS, Python version)
15:11:06 <felixfontein> but they could use pip if the default container is used, and whatever other solution when another container or remote is used
15:16:08 <mattclay> Why do you want to test with pip instead of OS packages? Is it just to get the latest version of the dependencies?
15:17:26 <felixfontein> first because OS packages are usually old, and second (more importantly) because OS packages don't work for most Python versions in the default container: ansible-test will complain that the environment changed afterwards
15:18:05 <felixfontein> the OS package versions are only for the Python version(s) the OS supports, not for all Python versions supported by the `default` container
15:18:24 <mattclay> The second part doesn't seem like a problem itself, since tests running on the Ubuntu 18.04 container would already cover the same thing.
15:19:48 <mattclay> Are you also trying to test on all or multiple python versions using the default container?
15:19:51 <felixfontein> yes. but I also want to run tests with say Python 2.6, and I cannot install pyOpenSSL with the OS package manager for that Python version
15:20:05 <felixfontein> so I have to use pip to install it
15:29:10 <felixfontein> I could use some criterion like "is specified Python version the default Python version for this OS", but that's a big workaround for something that could be solved much easier
15:30:18 <mattclay> OK, I think I have a pretty good understanding of the issue now. I'm not sure if the proposed solution is the right approach though. Something about using the environment to indicate the intent doesn't seem right, but I haven't thought of a better solution yet.
15:31:17 <mattclay> Does anyone else here have any thoughts on the issue or the proposed solution?
15:31:56 <felixfontein> I don't mind if there's another solution :) this one seemed kind of obvious since ansible-test is already providing some information in the environment
15:37:18 <mattclay> We have about 25 minutes left for this meeting. We can continue on the current discussion if there are no other topics to discuss.
15:37:27 <bcoca> go4it
15:38:59 <mattclay> felixfontein: Are you wanting to have this same behavior for all of the test targets in the collection?
15:40:33 <felixfontein> mattclay: do you mean tests other than integration tests? for my use-case no
15:42:16 <mattclay> felixfontein: No, I'm wondering how many of the different tests under `tests/integration/targets/` you'd like to use this for. Is it just one target, several of them, or the whole collection?
15:42:51 <felixfontein> ah, sorry
15:42:56 <felixfontein> probably a larger part of all targets
15:43:18 <felixfontein> (for some targets like luks_device it doesn't make sense)
15:44:00 <mattclay> What would be the desired behavior for those other targets? Just run the same tests as would run on Ubuntu 18.04, skip them, or something else?
15:44:21 <felixfontein> these targets should be skipped for the default container
15:45:07 <mattclay> How were you planning on skipping those?
15:46:10 <felixfontein> one idea would be to use shippable/group/posixX for all tests that should run on OSes, and cloud/... for all tests that should run with the default container. since the sanity test which prevents this is only in ansible-base, it works :)
15:46:37 <felixfontein> a better solution would probably be to skip all tasks if the default container is detected
15:46:50 <felixfontein> (when it is possible to detect the default container, that is)
15:46:55 <mattclay> So perhaps what we want to expose to the test isn't the container information, but which alias was used to trigger it.
15:47:33 <mattclay> Since that expresses the intended behavior (running platform-independent tests).
15:47:42 <felixfontein> that would also be fine
15:47:57 <mattclay> I'd need to think through how that would function a bit more though.
15:48:49 <felixfontein> btw, another problem I'm having is that I need to use cloud/acme to get the ACME test container running, and that's not compatible with the OS images
15:49:13 <mattclay> Why isn't it compatible?
15:49:53 <felixfontein> or at least I thought it isn't. if I run the shippable/group/posixX target, and one aliases file also contains cloud/acme, will the acme test container be started?
15:50:27 <felixfontein> I assumed that cloud/xxx is only used when the cloud target is ran, but right now I'm not sure whether I ever checked that, or just assumed it
15:50:46 <mattclay> It should work fine. There's a sanity test for ansible/ansible that would complain about that, but it doesn't apply to collections.
15:51:11 <felixfontein> ok, that would work for me then
15:51:14 <mattclay> The "cloud/" aliases are poorly named now. They were originally intended only for cloud tests, but quickly ended up being used for other purposes as well.
15:57:22 <mattclay> felixfontein: If we come up with a solution we like for running the tests in a platform-independent way, is it going to be useful to you if it's only in devel, or will it need to be backported through 2.9 to be worthwhile?
15:58:08 <felixfontein> having it in devel is a lot better than nothing. it would be nice to have it backported as well, but I can live with it not being backported
15:58:39 <mattclay> What will you do if it's not backported? Not run the platform independent tests, or use some work-around in the tests?
15:58:42 <felixfontein> we're running a limited subset of tests with 2.9 and 2.10 anyway, and only run the full battery with devel
15:59:07 <felixfontein> probably assume a default if the variable is not set, where the default will be "do what it currently does"
15:59:25 <felixfontein> (assuming it is an env variable)
15:59:42 <felixfontein> (or an ansible variable)
16:00:08 <mattclay> OK. I'll think about it more and see if I can come up with a solution that better allows us to express the intent when invoking the tests, so that we wouldn't need to rely on where the tests are running to get the platform independent behavior.
16:00:15 <felixfontein> i.e. setup_openssl / setup_pyopenssl will use OS packages, setup_acme will use pip by default
16:00:29 <felixfontein> sounds good! thanks!
16:00:50 <mattclay> That's it for this meeting. Thanks for coming.
16:00:54 <mattclay> #endmeeting