14:30:23 #startmeeting Pulp Triage 2019-06-21 14:30:23 #info asmacdo has joined triage 14:30:23 !start 14:30:23 Meeting started Fri Jun 21 14:30:23 2019 UTC. The chair is asmacdo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:23 The meeting name has been set to 'pulp_triage_2019-06-21' 14:30:23 asmacdo: asmacdo has joined triage 14:30:32 bmbouter: (+1) 14:30:54 #info daviddavis has joined triage 14:30:54 !here 14:30:54 daviddavis: daviddavis has joined triage 14:31:26 #info ggainey has joined triage 14:31:26 !here 14:31:26 ggainey: ggainey has joined triage 14:31:32 #info ppicka has joined triage 14:31:32 !here 14:31:32 ppicka: ppicka has joined triage 14:31:47 !next 14:31:48 asmacdo: 17 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4991, 4992, 4994, 4996, 4998, 5001, 5002, 5005, 5006, 5008 14:31:48 #topic https://pulp.plan.io/issues/4939 14:31:49 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:31:50 https://pulp.plan.io/issues/4939 14:32:04 ok im just gonna drive 14:32:05 skip 14:32:15 !issue 5005 14:32:15 #topic https://pulp.plan.io/issues/5005 14:32:16 RM 5005 - horakmar - NEW - RPM remote sync ignores "proxy_url" settings 14:32:17 https://pulp.plan.io/issues/5005 14:32:20 #info ttereshc has joined triage 14:32:20 !here 14:32:20 ttereshc: ttereshc has joined triage 14:32:25 accept and add to sprint? 14:32:47 also, unset category 14:32:49 I can take care of it, it's the part of the task which is blocked 14:32:59 so I can close it as a dupe I guess 14:33:08 great 14:33:10 #idea Proposed for #5005: ttereshc will close as dupe 14:33:10 !propose other ttereshc will close as dupe 14:33:10 asmacdo: Proposed for #5005: ttereshc will close as dupe 14:33:28 #agreed ttereshc will close as dupe 14:33:28 !accept 14:33:28 asmacdo: Current proposal accepted: ttereshc will close as dupe 14:33:29 asmacdo: 16 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4991, 4992, 4994, 4996, 4998, 5001, 5002, 5006, 5008 14:33:29 #topic https://pulp.plan.io/issues/4939 14:33:30 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:33:31 https://pulp.plan.io/issues/4939 14:33:32 daviddavis, the one eyou were looking at recently with all the one-time settings 14:33:36 !issue 4998 14:33:36 #topic https://pulp.plan.io/issues/4998 14:33:37 RM 4998 - daviddavis - NEW - Artifact size is limited to 2 GB 14:33:38 https://pulp.plan.io/issues/4998 14:33:58 #info dalley has joined triage 14:33:58 !here 14:33:58 dalley: dalley has joined triage 14:34:39 i was wondering if a separate story should be written (as an admin i can override default max artifact size) 14:34:51 #info bmbouter has joined triage 14:34:51 !here 14:34:51 bmbouter: bmbouter has joined triage 14:35:03 or if ^ should be part of this, which is just changing the datatype to allow bigger artifacts 14:35:59 I think we can defer this one (accept and not add to sprint) 14:36:01 what do you think? 14:36:06 #info dawalker has joined triage 14:36:06 !here 14:36:06 dawalker: dawalker has joined triage 14:36:29 bmbouter: thats fine by me 14:36:30 bmbouter: would this change external API when we do it? 14:36:36 no 14:36:42 kk, cool 14:36:47 it's such a small change and I think Katello will need this (eventually) 14:37:05 I probably should have just filed a PR instead of opening this issue 14:37:07 I know that I have seen 4Gb single-RPMs "in the wild" 14:37:21 !propose accept and add to sprint 14:37:21 asmacdo: propose accept Propose accepting the current issue in its current state. 14:37:21 I am fine with just accepting 14:37:27 yeah 14:37:34 daviddavis: !propose accept 14:37:37 ggainey, it's for any artifact, just any file 14:38:00 #idea Proposed for #4998: Leave the issue as-is, accepting its current state. 14:38:00 !propose accept 14:38:00 asmacdo: Proposed for #4998: Leave the issue as-is, accepting its current state. 14:38:08 +1 14:38:11 I have to redo the migrations so I might pick this up anyway 14:38:13 ttereshc: kk - makes it even more important then (because the 4Gb RPms were...for a kind of dumb reason, but 4Gb *files* are not at all uncommon) 14:38:23 ggainey, exactly 14:38:28 daviddavis: that's cool w/ me 14:38:29 #agreed Leave the issue as-is, accepting its current state. 14:38:29 !accept 14:38:29 asmacdo: Current proposal accepted: Leave the issue as-is, accepting its current state. 14:38:30 yea ISOs 14:38:30 #topic https://pulp.plan.io/issues/4939 14:38:31 asmacdo: 15 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4991, 4992, 4994, 4996, 5001, 5002, 5006, 5008 14:38:32 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:38:33 !issue 4994 14:38:33 #topic https://pulp.plan.io/issues/4994 14:38:34 https://pulp.plan.io/issues/4939 14:38:35 RM 4994 - iballou - NEW - Combine manifest-list-tag and manifest-tag models in Docker plugin 14:38:36 https://pulp.plan.io/issues/4994 14:38:36 yah 14:38:39 skip 14:38:44 +1 14:38:46 !skip 14:38:47 asmacdo: 14 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4991, 4992, 4996, 5001, 5002, 5006, 5008 14:38:47 #topic https://pulp.plan.io/issues/4939 14:38:48 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:38:49 https://pulp.plan.io/issues/4939 14:38:52 skip 14:38:54 ha! 14:38:54 yup 14:38:54 !issue 4992 14:38:55 #topic https://pulp.plan.io/issues/4992 14:38:55 RM 4992 - jsherril@redhat.com - NEW - 'fields' parameter is not available in api docs/bindings 14:38:56 https://pulp.plan.io/issues/4992 14:39:24 is this just an api-doc issue? 14:39:31 there should be a P tag on this I htink 14:39:35 it's an apiSchema issue 14:39:37 ggainey: im betting that if its not documented, it doesnt work 14:39:44 yea not in the bindings 14:39:45 heh, kk 14:39:45 it's not that it's missing from the docs 14:40:18 this seems important 14:40:18 #idea Proposed for #4992: accept, add to sprint, add bindings tag 14:40:18 !propose other accept, add to sprint, add bindings tag 14:40:18 ttereshc: Proposed for #4992: accept, add to sprint, add bindings tag 14:40:25 +1 14:40:25 +1 14:40:29 asmacdo, it works 14:40:29 +1 14:40:46 it's not in the api docs but it does work 14:40:53 it works but probably not from the bindings 14:40:54 dalley it works in the bindings? 14:40:59 no not in the bindings 14:41:02 sorry 14:41:05 misunderstood 14:41:06 our docs and bindings all come from the schema 14:41:28 so anytime it's wrong usually we have to add the schema decorators 14:41:52 accepting... 14:42:04 #agreed accept, add to sprint, add bindings tag 14:42:04 !accept 14:42:04 asmacdo: Current proposal accepted: accept, add to sprint, add bindings tag 14:42:06 #topic https://pulp.plan.io/issues/4939 14:42:06 asmacdo: 13 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4991, 4996, 5001, 5002, 5006, 5008 14:42:07 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:42:08 https://pulp.plan.io/issues/4939 14:42:11 !issue 4991 14:42:11 #topic https://pulp.plan.io/issues/4991 14:42:12 RM 4991 - jsherril@redhat.com - NEW - Creating a repository version with many thousands of units fails 14:42:13 https://pulp.plan.io/issues/4991 14:42:18 (sorry for spamming you kersom) 14:42:36 no problem at all 14:42:54 I think this is probably a docs issue 14:43:43 the 4MB limit? 14:43:46 so "document maximum request body size" 14:43:48 yeah, I'm not sure what we can do 14:43:50 aye 14:44:11 the only alternative i can think is to support some sort of multi-request version creation 14:44:12 #idea Proposed for #4991: change to documentation issue 14:44:12 !propose other change to documentation issue 14:44:12 asmacdo: Proposed for #4991: change to documentation issue 14:44:13 document the limit and maybe how to increase it if it's possible 14:44:27 which seems like an advanced feature for the future, but nothing really to do now IMO 14:44:35 concur 14:44:36 yea, that would be neat 14:44:36 jsherrill: like burning a cd without finalizing it :) 14:44:41 asmacdo: yep! 14:44:49 * daviddavis has flashbacks 14:44:52 i think our mechanisms are actually in place for that 14:45:14 might not be as hard as it seems, but still 3.1+ 14:45:20 aye 14:45:38 is 4991 root caused on the artifact file size limit? 14:45:54 no it's request size 14:46:02 it's limited by the size of web requests 14:46:11 and the fact we use hrefs makes it more likely 14:46:11 i would say its assumed to be a web request size limit 14:46:14 ic 14:47:01 accept as docs issue? 14:47:13 for now 14:47:32 yeah, jsherrill a separate story for the cd-burner story 14:47:33 +1 14:47:34 +1 14:47:35 +1 14:47:39 #agreed change to documentation issue 14:47:39 !accept 14:47:39 asmacdo: Current proposal accepted: change to documentation issue 14:47:40 asmacdo: 12 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4989, 4990, 4996, 5001, 5002, 5006, 5008 14:47:40 #topic https://pulp.plan.io/issues/4939 14:47:41 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:47:42 please call it the cd burner story too 14:47:43 https://pulp.plan.io/issues/4939 14:47:49 haha 14:47:50 !4989 14:47:50 asmacdo: Error: "4989" is not a valid command. 14:47:59 !issue 4989 14:47:59 #topic https://pulp.plan.io/issues/4989 14:48:00 RM 4989 - mdellweg - ASSIGNED - Api bindings for python use unnecessary verbose action names 14:48:01 https://pulp.plan.io/issues/4989 14:48:16 skip for now 14:48:32 +1 14:48:54 i think we should accept 14:48:59 dkliban is working on this 14:49:12 I would wait to get his input 14:49:19 I think he'll probably be adding this to the sprint 14:49:28 fine by me 14:49:32 yeah, looks like he's already got some of the work done, yeah? 14:49:32 !kip 14:49:35 asmacdo: Error: "kip" is not a valid command. 14:49:36 !skip 14:49:37 asmacdo: 11 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4990, 4996, 5001, 5002, 5006, 5008 14:49:37 #topic https://pulp.plan.io/issues/4939 14:49:38 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 14:49:39 https://pulp.plan.io/issues/4939 14:49:54 ggainey: i figure we just let him mark it up however it needs 14:49:58 yeah 14:50:02 +1 14:50:04 so thats it, the end of the triagable issues 14:50:10 open floor! 14:50:10 5008 please 14:50:18 !issue 5008 14:50:18 #topic https://pulp.plan.io/issues/5008 14:50:19 RM 5008 - ttereshc - NEW - No way to enforce content specific uniqueness constaints in a repo version 14:50:20 https://pulp.plan.io/issues/5008 14:50:43 bmbouter, this is the one we were talking about at sprint planning 14:50:53 related to pulp-dev thread 14:51:36 will we remove RemoveDuplicates stage with this change? 14:51:45 i dont think we can do this 14:51:52 daviddavis, it depends how we design it 14:52:12 if it is with any content addition, I think it makes sens eto remove it 14:52:24 asmacdo, why can't we? 14:52:26 yea, just want to make sure we aren't duplicating code 14:52:29 the trouble is that add/remove is a pulpcore endpoint 14:52:49 how does the plugin writer have an opportunity to pass information like how to use RemoveDuplicates to core? 14:52:52 the RH vpn keeps dropping out for me 14:52:58 I have alot to say but can't :( 14:53:12 ttereshc: you know the issue where our wifi drops... 14:53:21 oh 14:53:35 I'd like anyone who has a proposal on how to do this to write on the issue 14:53:38 asmacdo: in one of the proposed designs, the plugin writer can set a unique repo key or some value that core will check 14:53:45 what we have discussed in the past is that plugins needing advanced add/remove stuff should just provide their own endpoints, and tell users not to use POST repo versions 14:53:46 +1 14:54:32 there were other options we should consider those too 14:54:56 and there are slightly different concerns the concern here is about uniqueness 14:55:08 so I imagine two solutions: one would be a set of db fields that a plugin writer can specify. if that's not enough, a hook that a plugin writer can specify if the info isn't in the db. 14:55:20 yup 14:56:05 we should encourage the former though. if the app has to calculate uniqueness itself, it's going to be really slow. 14:56:07 i have a conceptual problem with that 14:56:36 the pulpcore <--> plugin interface everywhere else in pulp specifically avoids the hook pattern 14:57:08 to me, we just haven't used it yet 14:57:39 bmbouter: we can always do that, but i think having a strict pattern of how the plugin api works keeps it simple 14:58:01 it sounds like we won't be able to achieve ou goals if its left that simple 14:58:12 we could not have a hook and allow the repo key to contain properties which could be calculated. 14:58:16 the plugin writers can provide custom endpoints 14:58:33 creating a repository version is easy, call whatever code you want 14:58:37 there is also the "other" problem which isn't uniqueness but "closure" 14:58:46 and I think kwe need to comprehensively handle both 14:59:10 i'm not convinced that any hooks we make can be general enough 14:59:27 i think the plugin writer needs to be able to do whatever they need-- possibly even adding arguments 15:00:30 I would need to see proposals and options before I can say if it will/wont be viable 15:00:45 * daviddavis cringes at the idea of typed repo versions 15:01:06 and my goal is to broaden the scope to be both about uniqness and closure 15:01:22 what if a repo version contains two content types from two different plugins? how do we handle that if each plugin defines its own repo veroisn creation endpoint? 15:01:36 heres my main point-- we are really close to GA. lets not try to solve all the plugins problems that they can solve themselves 15:01:50 especially, lets not introduce a whole new pattern 15:02:13 maybe this stuff can simplify plugins, but this can be done with custom endpoints as-is 15:02:24 #info mikedep333 has joined triage 15:02:24 !here 15:02:24 mikedep333: mikedep333 has joined triage 15:02:44 users using add/remove endpoints (from core) can corrupt their repo versions 15:02:49 and there is nothing plugins can do about that 15:03:03 corrupt in the sense that it's in pulp, but when a user goes to use it it would never work 15:03:29 yea, but if I use a repo verison creatoin endpoint for eery other plugin, I would be surprised if some plugin doesn't use it 15:03:39 and then I would be angry if it corrupted my repo version 15:03:49 it also doesn't look right to me that we introduced a generic thing for the sync (RemoveDuplicates) but for the copy we need to do some custom stuff and enforce the same restrictions 15:03:57 bmbouter: if a repo version is corrupted, it could also be fixed by the "manual add/remove" 15:04:09 yup 15:04:33 possibly 15:04:47 it might be too hard to fix in some cases 15:04:49 asmacdo: sure but the concern I heard was that pulp is unsafe to use 15:05:12 we really need various proposals and consider them 15:05:18 yea agreed 15:05:25 and hen if we can't do any of them then we'll know for sure 15:05:31 we could make a master/detail add-remove endpoint 15:05:47 and if it's too bit, or too close to GA we can decide we can't do them for risk/release resone 15:05:48 IMO that would be the simplest way, and it would preserve existing patterns 15:05:55 s/bit/big/ 15:06:41 we need to have the proposals written to really consider them (I think) 15:06:52 sure 15:06:54 pros/cons/risk-assessment all that 15:07:06 so, lets take this back to the list? 15:07:22 list or the issue 15:07:34 +1 email list that all should comment on issue 15:07:50 let's write proposals on the issue and bring them to the list 15:07:57 this sounds great 15:08:17 concur 15:08:26 asmacdo: and if they're too big, not right, etc we can choose not too (I hear you) 15:08:41 s/too/to/ :) 15:08:46 yeah all that sounds great -- i was jumping ahead a bit 15:09:29 great, thank you all, I'm glad I was able to bring attention to this one 15:09:41 +1 15:10:05 asmacdo: it's all good 15:10:08 know why? 15:10:11 !friday 15:10:11 ♪ It's Friday, Friday, gotta get down on Friday ♪ 15:10:16 * daviddavis dances 15:10:20 * bmbouter moonwalks 15:10:28 lol 15:10:37 any other open floor business? 15:10:39 bmbouter, you mentioned changed the #4990 from ansible to pulpcore 15:10:51 yes 15:10:59 let's chat on that 15:11:42 pulp_ansible doesn't support on-demand (not lazy :) and it won't for a while 15:12:54 and so as a user of pulp_ansible you can specify policy to whatever value you want and it will validate even though the plugin code totally ignores it 15:13:05 so the concern is usability 15:13:36 and the desire is for a plugin that hasn't taken action to "enable on-demand" should fail validation at Remote create/update time if on-demand is set to anything except the default which is 'immediate' 15:13:51 and that would need to be done in core... 15:15:08 I loosely described it here https://pulp.plan.io/issues/4990#note-2 15:15:22 the idea is the policy attribute would be shown in the serializer in core still 15:15:31 so no visible change for users 15:15:47 the only test that we have related to this is attempt to create a remote using a non valid - policy, and exception is raised...but we do not test if certain plugin that does not support lazy...and what outcomes of this. 15:15:52 but the validator would specifically fail validation if policy != 'immediate' 15:16:29 and all plugins would enable lazy by adjusting the serializer's validation in their Remote's subclass 15:16:31 not being able to even to create a remote, right? 15:16:35 correct 15:16:42 +1 15:17:07 and 4990 would become a core issue and I propose a RC3 blocker 15:17:16 they could even define their own policies other than the ones we have now? 15:17:37 daviddavis: that gets a lot trickier 15:17:41 oh ok 15:17:53 because these policy types are made w/ features that come together in various cmponents 15:17:54 i see, choices would be defined on pulpcore, but validated against by default 15:18:00 and those components aren't fully pluggable atm 15:18:09 I see 15:18:18 asmacdo: yes 15:18:45 if we make ^ change in rc3 it would require all plugins that support lazy to release compat releases (which should be done anywya) 15:18:53 so there would be a superset of policy opts and each lugin defines its own subset 15:18:53 and I think we should do that 15:19:00 yes 15:19:01 +1 15:19:23 let's move it to core and add it to the sprint and rc3 blockers 15:19:35 woot 15:20:01 And update description to match the plan 15:20:16 daviddavis: want me to doo all ^ now? 15:20:24 sure go for it 15:20:30 I'll update description too and add to rc3 blocker list 15:20:40 i guess lets call it on open floor 15:20:40 and probably send email to the rc3 thread 15:20:44 ty 15:20:46 +1 15:20:53 great discussion 15:20:54 #endmeeting 15:20:54 !end