15:30:09 #startmeeting Pulp Triage 2020-02-18 15:30:09 !start 15:30:09 Meeting started Tue Feb 18 15:30:09 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:30:09 The meeting name has been set to 'pulp_triage_2020-02-18' 15:30:09 #info fao89 has joined triage 15:30:10 fao89: fao89 has joined triage 15:30:13 !next 15:30:14 fao89: No issues to triage. 15:30:18 #info daviddavis has joined triage 15:30:18 !here 15:30:18 daviddavis: daviddavis has joined triage 15:30:20 Open floor! 15:30:21 #info ttereshc has joined triage 15:30:21 !here 15:30:21 ttereshc: ttereshc has joined triage 15:30:36 #info ppicka has joined triage 15:30:36 !here 15:30:36 ppicka: ppicka has joined triage 15:31:28 #info dkliban has joined triage 15:31:28 !here 15:31:28 dkliban: dkliban has joined triage 15:31:52 anyone have anything they wish to discuss? 15:32:46 #info mikedep333 has joined triage 15:32:46 !here 15:32:46 mikedep333: mikedep333 has joined triage 15:33:08 !not_here_anymore 15:33:08 ttereshc: Error: "not_here_anymore" is not a valid command. 15:33:10 Just hold off on merging the GHA support until our CI meeting. 15:33:49 I want to discuss the nested virtualization testing, where Travis with hardware KVM virtualization is the clear winner over GHA's 2 options. 15:34:12 given the dependency issue on ansible-pulp and pulp_rpm_prerequisites, I have a question, does someone is familiarized with poetry? https://python-poetry.org/docs/ 15:34:31 does it worth to try it on pulp? 15:35:01 mikedep333: the virtualization on Travis is a clear winner 15:35:30 fao89: I evaluated it earlier. It looks useful, but does not solve our even bigger need: Identifying the newest plugin version compatible with a specific pulpcore version. 15:35:37 mikedep333: i think that we can probably move all our tests to GHA and then additionally run one build on Travis that uses virtualization to test CentOS7 with SELInux 15:36:14 dkliban: Yeah. It's the fastest, supports 64-bit, and requires no changes to pulplift on our part. 15:36:30 mikedep333: I think pipdeptree is the best tool for that 15:36:54 when I had a conflicting environment it at the very top said exactly what package was conflicting and why 15:37:21 virtualbox software virtualization on GHA is medium speed, but lacks 64-bit guest support. It's simply a never implemented feature; software virt is virtualbox's legacy mode. 15:37:40 https://github.com/naiquevin/pipdeptree#whats-with-the-warning-about-conflicting-dependencies 15:37:44 qemu emulation on GHA is just too slow, although it meets all the other criteria. 15:37:52 mikedep333: the installer should use pipdeptree to run the pre-flight check 15:38:39 the issue is that you'd have to install them first in like a dummy virtualenv 15:38:39 bmbouter: I agree, I may end up using it. I just want to try to come up with a design that includes enumerating the compatible plugins with the pulpcore version before I start implementing a preflight check for the values users specify. 15:38:41 but that's ok 15:39:14 what does 'enumerating the compatible plugins with pulpcore version' mean? 15:39:41 say a user is about to install pulpcore 3.2.1 with ansible-pulp 3.2.1. 15:40:39 pulp_rpm, pulp_file, may have compatible releases with pulpcore 3.2.1, but pulp_maven may not yet. 15:40:46 And what if pulpcore 3.3.0 is out, and the user must stay on pulp_file 0.3.0 and not install the new pulp_file 0.4.0? 15:41:13 or rather, must install pulp_file 0.3.0, rather than install 0.4.0, if pulp_file is current not installed. 15:42:03 Ideally a 3rd party would look at all the versions of the plugins on PyPI, and see what versions of pulpcore they support, and pick the newest plugin version that supports the fixed pulpcore version. 15:42:18 *3rd party library/command 15:43:02 I hear your examples, but where does the user enumeration part come in? 15:43:42 During pre-flight, or during the install, the pulpcore version is fixed, and the user specified a list of plugins they want by name, without version. 15:44:41 We can't just have pulpcore fixed (via constraints) at a version, and do the equivalent of "pip install pulp_file", because it will install the newest version of pulp_file, period. 15:45:59 call me crazy but if we had the pre-flight check we could 15:46:14 it would just stop the user in all unsafe, i.e. package conflicting scenarios 15:46:25 this conversation is confusing to me 15:47:01 yea, I stopped following once we started talking about virt in Travis and dependencies in pulp at the same time 15:47:11 * daviddavis rereads 15:47:12 mikedep333: i think we should do a call about the installer 15:47:20 bmbouter: Yes, we could avoid unsafe scenarios. But it won't help the user figure out how to resolve them. how to adjust the version string to get a compatible version. 15:47:36 bmbouter: mikedep333: i am going to schedule a call for us to get on the same page about this 15:47:38 We'd be like RPM complaining, not like yum/dnf/zipper offering a solution. 15:47:42 OK, let's do so. 15:47:58 I'll dig up the existing redmine ticket for this. 15:48:26 I mean, this is something I want to spend time on badly. I am just trying to complete other more urgent stuff 1st. 15:48:32 I want to participate in that call 15:50:13 fao89: sounds good 15:51:51 fao89: wrt https://github.com/pulp/pulplift/pull/66 , I specified: on: [push, pull_request] 15:51:56 What else do I need to add? 15:52:36 I think just it 15:53:04 mikedep333: are you trying to run this PR in GHA? I don't think PRs will run until the config is merged 15:53:57 yeah, for running PR on GHA, you have to open a PR against your fork 15:54:00 daviddavis: Yes, on both GHA and travis. 15:54:19 fao89: Ack, I'll try that. As long as others can see the GHA results and Travis results. 15:54:39 just put a link on your PR description 15:54:41 mikedep333: fao89 just posted links to his results 15:55:07 can I finish open floor? 15:55:41 i think so 15:55:45 +1 15:55:56 #endmeeting 15:55:56 !end