14:30:49 #startmeeting Pulp Triage 2020-05-19 14:30:49 !start 14:30:49 #info fao89 has joined triage 14:30:49 Meeting started Tue May 19 14:30:49 2020 UTC. The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:49 The meeting name has been set to 'pulp_triage_2020-05-19' 14:30:49 fao89: fao89 has joined triage 14:30:59 #info ppicka has joined triage 14:30:59 !here 14:30:59 ppicka: ppicka has joined triage 14:31:17 !next 14:31:18 fao89: 6 issues left to triage: 6767, 6762, 6756, 6755, 6750, 6714 14:31:18 #topic https://pulp.plan.io/issues/6767 14:31:19 RM 6767 - daviddavis - NEW - Tests are failing sometimes due to 500 for pulp-fixtures 14:31:20 https://pulp.plan.io/issues/6767 14:31:21 #info daviddavis has joined triage 14:31:21 !here 14:31:22 daviddavis: daviddavis has joined triage 14:31:27 #info bmbouter has joined triage 14:31:27 !here 14:31:27 bmbouter: bmbouter has joined triage 14:31:40 #idea Proposed for #6767: accept and add to sprint 14:31:40 !propose other accept and add to sprint 14:31:40 fao89: Proposed for #6767: accept and add to sprint 14:31:46 #info dalley has joined triage 14:31:46 !here 14:31:46 dalley: dalley has joined triage 14:32:33 #info x9c4 has joined triage 14:32:33 !here 14:32:33 x9c4: x9c4 has joined triage 14:32:50 I think I had an AI to do this a while ago 14:32:55 so +1 to accept and add to sprint 14:32:55 #info dkliban has joined triage 14:32:56 !here 14:32:56 dkliban: dkliban has joined triage 14:33:05 #agreed accept and add to sprint 14:33:05 !accept 14:33:05 fao89: Current proposal accepted: accept and add to sprint 14:33:06 fao89: 5 issues left to triage: 6762, 6756, 6755, 6750, 6714 14:33:06 #topic https://pulp.plan.io/issues/6762 14:33:07 RM 6762 - david.macneil@actual-experience.com - NEW - Cannot sync a remote that's using a x509 content guard 14:33:08 https://pulp.plan.io/issues/6762 14:33:24 * bmbouter reads 14:33:50 it's because of the header thing 14:33:52 yup 14:34:00 * bmbouter is real glad we switched to TLS submission 14:34:12 bmbouter: can you reply tot he issue? 14:34:22 yes and can we move to certguard project 14:34:31 and we should accept and not add to the sprint at ths time. what do you think bmbouter? 14:34:40 yes accept not add to sprint 14:34:48 #idea Proposed for #6762: Leave the issue as-is, accepting its current state. 14:34:48 !propose accept 14:34:48 fao89: Proposed for #6762: Leave the issue as-is, accepting its current state. 14:34:50 this is going to work if he uses the newest version, but we need to also add a test 14:34:52 #agreed Leave the issue as-is, accepting its current state. 14:34:52 !accept 14:34:52 fao89: Current proposal accepted: Leave the issue as-is, accepting its current state. 14:34:53 fao89: 4 issues left to triage: 6756, 6755, 6750, 6714 14:34:53 #topic https://pulp.plan.io/issues/6756 14:34:53 and move to certguard 14:34:54 RM 6756 - deepthireddy21 - NEW - Pulp celery with Mongodb replica sets 14:34:55 https://pulp.plan.io/issues/6756 14:35:51 #idea Proposed for #6756: Leave the issue as-is, accepting its current state. 14:35:51 !propose accept 14:35:51 dkliban: Proposed for #6756: Leave the issue as-is, accepting its current state. 14:36:00 wait we won't fix tho 14:36:18 yea, I thought we were going to either fix or close for pulp 2 14:37:16 #idea Proposed for #6756: close- won't fix 14:37:16 !propose other close- won't fix 14:37:16 dkliban: Proposed for #6756: close- won't fix 14:37:25 also invite user to switch to pulp3 14:37:32 +1 14:37:33 yeah ... i'll comment on it and do the closing 14:37:40 dkliban++ 14:37:40 daviddavis: dkliban's karma is now 471 14:37:43 #agreed close- won't fix 14:37:43 !accept 14:37:43 fao89: Current proposal accepted: close- won't fix 14:37:44 fao89: 3 issues left to triage: 6755, 6750, 6714 14:37:44 #topic https://pulp.plan.io/issues/6755 14:37:45 RM 6755 - swisscom - NEW - pulpcore-manager error "You must specify the CONTENT_ORIGIN setting" 14:37:46 https://pulp.plan.io/issues/6755 14:38:09 oh this error is by design to instruct the user they have to set this 14:38:17 the user says we can close it out 14:38:23 s/user/reporter/ 14:38:29 yep ... gerrod filed a similar issue yesterday 14:38:29 #idea Proposed for #6755: close it as notabug 14:38:29 !propose other close it as notabug 14:38:29 fao89: Proposed for #6755: close it as notabug 14:38:38 and we will close that one today alos 14:39:00 we need a better error message for that I think 14:39:07 that would be a good way to transition the bug 14:39:16 https://github.com/pulp/pulpcore/blob/master/pulpcore/app/settings.py#L233 14:39:29 actually I'll file it 14:39:33 +1 14:39:35 bmbouter: and i'll comment 14:39:35 I have specific ideas on how to resolve this 14:39:47 it's usually a permissions problem 14:39:53 with the /etc/pulp/settings.py 14:40:08 for this issue, what should I do? Close it? 14:40:45 i think so. bmbouter? ^ 14:41:02 use says close it +1 to that 14:41:06 I'm filing a new issue now 14:41:20 #agreed close it as notabug 14:41:20 !accept 14:41:20 fao89: Current proposal accepted: close it as notabug 14:41:23 #topic https://pulp.plan.io/issues/6750 14:41:23 fao89: 2 issues left to triage: 6750, 6714 14:41:24 RM 6750 - dkliban@redhat.com - NEW - CI doesn't show output of container build logs 14:41:25 https://pulp.plan.io/issues/6750 14:42:03 #idea Proposed for #6750: accept and add to sprint 14:42:03 !propose other accept and add to sprint 14:42:03 fao89: Proposed for #6750: accept and add to sprint 14:42:06 +1 14:42:32 #agreed accept and add to sprint 14:42:32 !accept 14:42:32 fao89: Current proposal accepted: accept and add to sprint 14:42:33 #topic https://pulp.plan.io/issues/6714 14:42:33 fao89: 1 issues left to triage: 6714 14:42:34 RM 6714 - alikins - NEW - drf builtin manage.py 'generateschema' command fails on pulp base viewsets 14:42:35 +1 Ill comment on it, 14:42:36 https://pulp.plan.io/issues/6714 14:43:01 let's skip it and i'll reach out to the filer 14:43:06 i commented but he didn't notice 14:43:12 !skip 14:43:13 !propose skip 14:43:14 fao89: No issues to triage. 14:43:15 dkliban: Error: No current issue, proposal ignored. 14:43:21 lol 14:43:27 Open floor - https://hackmd.io/SVCMjpwXTfOMqF2OeyyLRw 14:43:52 pulpcore 3.4.0 release date proposal: May 27th 14:44:19 this is a Wednesday after the Memorial day holiday in the US 14:45:13 yes giving a business day in the US is the thinking 14:45:30 if we accept this, we would want to advertise this timleine on pulp-dev 14:45:54 that all sounds good to me 14:46:35 any concerns w/ this timeline or counterproposal? 14:47:38 none from me 14:47:47 I have one 14:47:52 who's going to do it 14:48:00 oh yeah good question 14:50:22 well, it's been a while since i've done it 14:51:15 i will do it 14:51:22 * daviddavis cheers wildly 14:51:24 lol 14:52:21 next topic? 14:52:33 What should block this release? 14:53:06 #action dkliban will do the 3.4.0 on May 27th 14:53:06 !action dkliban will do the 3.4.0 on May 27th 14:53:28 i'll send a note to pulp-dev list announcing this date also 14:53:35 I was thinking we could approach this as "should block" the release and then as we get closer make a final decision 14:53:49 dkliban: thank you and we want a call for blocker in that announcement 14:53:49 sounds good to me 14:54:30 I was hoping we could have all the write_field issues resolved w/ this release 14:54:40 +1 14:54:47 the audit one mdellweg was looking at and another if there is one 14:54:51 but I don't have issue numbers unfortuantely 14:55:02 https://pulp.plan.io/issues/6421 14:55:18 and the other one needs to still be filed i think 14:55:56 ok 6421 and the yet-to-be-filed fixes for pulpcore's use of write_only (which is also our next topic btw) 14:56:00 and i would characterize it as 'bindings can't be used to upload Content in a single api call' 14:56:15 how do folks feel about those to be tagged with 3.4.0? 14:56:23 which is the mechanism I think we'll use 14:56:38 i would love it if we finally resolved this 14:58:26 so i feel good 14:58:42 ok please bring up any concerns if there are any 14:59:36 #action tag 6421 and yet-to-be-filed pulpcore write_only issue as 3.4.0 blocker 14:59:36 !action tag 6421 and yet-to-be-filed pulpcore write_only issue as 3.4.0 blocker 14:59:42 fao89: I wonder if ^ worked 15:00:03 here's a blocker that is already set but it won't be ready https://pulp.plan.io/issues/6460 15:00:11 it is a matter of faith, haha 15:00:25 I propose we remove the blocker tag from it, katello has a workaround already so I think that is ok 15:00:44 last time it worked, unfortunately pulpbot does not send any message for this command 15:00:50 np 15:03:39 * bmbouter falls alseep 15:04:17 ok let's move on sounds like there are no concerns 15:04:26 next topic? 15:04:28 #action remove 6460 as blocker, katello has a workaround and the patch isn't ready 15:04:28 !action remove 6460 as blocker, katello has a workaround and the patch isn't ready 15:04:33 almost 15:04:45 this is the last blocker we talked about https://pulp.plan.io/issues/6369 15:04:53 the last one I had at least 15:05:03 yep ... i think we need to resolve this also 15:05:40 +1 15:05:56 #action add 3.4.0 blocker tag to https://pulp.plan.io/issues/6369 15:05:56 !action add 3.4.0 blocker tag to https://pulp.plan.io/issues/6369 15:06:38 those are the only blockers I was thinking of so I'm good to move on 15:07:13 #action dkliban to file a bug about not being able to upload content in single call using bindings 15:07:13 !action dkliban to file a bug about not being able to upload content in single call using bindings 15:08:41 next topic: 15:08:44 review write_field usage audit 15:08:46 https://pulp.plan.io/issues/6421#note-9 15:10:29 so I'm focusing on the pulpcore ones only here 15:10:54 i am a bit confused about the pulpcore ones 15:10:58 relative_path on the SingleArtifactContentSerializer OK, since there is no relative_path in the database model. Also it is dynamically deactivated. 15:11:23 it sounds like we should keep this field as write_only 15:11:27 If the content decides to have a relative_path write_only is set to False. 15:11:42 gotcha 15:11:56 i think we can keep this one 15:11:58 so to me we need to remove write_only entirely because the openapi schema we use does not allow it 15:12:19 I intepret 'OK' as a legitimate use for a write-only-like-behavior 15:12:31 bmbouter: did you see the latest discussion ont he write_only thread? 15:12:47 I don't think I did 15:12:48 * dkliban pulls it up 15:13:24 bmbouter: https://www.redhat.com/archives/pulp-dev/2020-April/msg00101.html 15:14:25 oh yes I did read this 15:14:55 to recap my understanding on this solution: the effect is that the bindings will two serializers is that right? 15:15:07 s/will two/will get two/ 15:15:10 yes, that's right 15:15:30 even if dont' do it automatically, we will still need to provide 2 serializers 15:15:46 agreed this matches what I think is the path forward also 15:16:21 and how many models does that make for an object w/ 2 serializers? 15:16:40 Content models 15:16:59 PulpExportSerializer 15:17:19 UploadChunkSerializer 15:17:21 so for one of those examples... does it get two models? 15:17:39 FileContent and FileContentWrite 15:17:54 Actually FileContent and FileContentRead 15:17:55 PulpExport and PulpExportWrite 15:18:00 oops 15:18:02 thank you x9c4 15:18:10 great this is making sense to me, ty both 15:18:15 PulpExport and PulpExportRead 15:18:36 so they get two models and ^ are their names 15:18:42 yep 15:18:44 just like the email says 15:18:56 ok I'm ready to go back to the content from https://pulp.plan.io/issues/6421#note-9 15:19:06 And no user ever instanciates the secon one by hand. 15:19:10 yup 15:19:29 so let me ask this: if we continue to have write_only ... that won't ever make it into the openapischema itself? 15:20:03 that's right ... we will always split it up into two serializers 15:20:16 and fields won't be marked as write_only in the schema 15:20:37 great 15:20:44 because that does not exist in the schema? 15:20:49 yep 15:20:52 yes it's not allowed in V2 15:21:01 which is one of my main concerns, but this plan addresses that 15:21:02 fine. 15:21:32 bmbouter: at some point we will need to transition to v3, but we can discuss that later down the road 15:22:05 but i don't want to rush that right now 15:22:15 agreed 15:22:27 dkliban: so I'm back to the question you asked... 15:23:02 you have to repeat it cause i forgot 15:23:30 I don't understand "relative_path on the SingleArtifactContentSerializer OK, since there is no relative_path in the database model. Also it is dynamically deactivated." 15:23:46 oh yes, i understand it now 15:24:01 this concerns the Content serializers 15:24:14 and we allow users to upload content directly into a repository 15:24:35 even wihtout the repository part, we allow users to upload a file and create content out of it 15:24:46 that content needs a relative path for the content artifact 15:24:51 yes 15:25:12 Not necessarily. 15:25:24 so we allow users to specify the relative path at creation time, but we don't always return it. unless it's like FileContent which does have a relative_path field 15:25:37 x9c4: please explain 15:25:45 Only if the path to publish it is not determined by other menas while publishing. 15:26:19 even for those units currently, don't they have a relative path set on content artifact? 15:26:34 I think it can be None/Nil 15:26:37 oh ok 15:27:21 This does not work with passthrough publishing for obvious reasons. 15:27:41 actually we don't allow null right now https://git.io/JfzkW 15:28:12 time check 15:28:20 i have a hard stop at 11:3- 15:28:23 me also 15:28:25 me too 15:28:36 so let's revisit on friday I can push it to the agenda there as prep 15:29:02 but for the fields that have write_only we'll need the serizlier splitter 15:29:08 do we have a POC PR w/ that implementaiton? 15:29:15 fao89: maybe you had it at one point? 15:29:47 I closed a PR that did that 15:30:30 fao89: would you be able to open that back up so we can look at on friday? 15:30:32 https://github.com/pulp/pulpcore/pull/600 15:30:53 it needs secretCharField stuff removed 15:31:00 yep 15:31:00 fao89: i'll file a new issue to associate with that PR 15:31:04 I'll do it 15:31:07 ty and ty 15:31:10 that's our time 15:31:16 thank you all 15:31:20 #endmeeting 15:31:20 !end