15:30:08 #startmeeting Pulp Triage 2019-06-18 15:30:08 #info asmacdo has joined triage 15:30:08 !start 15:30:08 Meeting started Tue Jun 18 15:30:08 2019 UTC. The chair is asmacdo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:08 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:30:08 The meeting name has been set to 'pulp_triage_2019-06-18' 15:30:08 asmacdo: asmacdo has joined triage 15:30:16 #info daviddavis has joined triage 15:30:16 !here 15:30:16 daviddavis: daviddavis has joined triage 15:30:19 #info bmbouter has joined triage 15:30:19 !here 15:30:19 bmbouter: bmbouter has joined triage 15:30:21 !next 15:30:22 asmacdo: 7 issues left to triage: 4920, 4939, 4947, 4959, 4970, 4979, 4987 15:30:22 #topic https://pulp.plan.io/issues/4920 15:30:23 RM 4920 - kersom - ASSIGNED - Collection - Repository versions not being update after successive syncs 15:30:24 https://pulp.plan.io/issues/4920 15:30:26 skip 15:30:32 #info ttereshc has joined triage 15:30:32 !here 15:30:32 ttereshc: ttereshc has joined triage 15:30:38 dkliban: i guess we have more to do 15:30:45 * daviddavis weeps 15:30:46 !skip 15:30:47 #topic https://pulp.plan.io/issues/4939 15:30:47 asmacdo: 6 issues left to triage: 4939, 4947, 4959, 4970, 4979, 4987 15:30:48 RM 4939 - kersom - NEW - Docs - Collections upload workflows is using role endpoints 15:30:48 * daviddavis weeps 15:30:49 https://pulp.plan.io/issues/4939 15:30:54 skip 15:30:56 !skip 15:30:57 asmacdo: 5 issues left to triage: 4947, 4959, 4970, 4979, 4987 15:30:57 #topic https://pulp.plan.io/issues/4947 15:30:58 RM 4947 - amacdona@redhat.com - NEW - As a user I can add tags to a repository by name. 15:30:59 skip 15:30:59 https://pulp.plan.io/issues/4947 15:31:05 !skip 15:31:06 story? 15:31:06 #topic https://pulp.plan.io/issues/4959 15:31:07 asmacdo: 4 issues left to triage: 4959, 4970, 4979, 4987 15:31:08 RM 4959 - amacdona@redhat.com - NEW - Do not log that a download fails with 401 (INFO) unless it fails again after token refresh 15:31:09 https://pulp.plan.io/issues/4959 15:31:19 !skip 15:31:20 asmacdo: 3 issues left to triage: 4970, 4979, 4987 15:31:20 #topic https://pulp.plan.io/issues/4970 15:31:21 RM 4970 - kersom - NEW - Collection - RepositoryDistribution does not provide url to consume to cosume content from Pulp 15:31:22 https://pulp.plan.io/issues/4970 15:31:36 !skip 15:31:37 asmacdo: 2 issues left to triage: 4979, 4987 15:31:37 #topic https://pulp.plan.io/issues/4979 15:31:38 RM 4979 - dgoetz - NEW - Katello complains during reposync about being unable to update existing errate 15:31:39 https://pulp.plan.io/issues/4979 15:31:46 !skip 15:31:47 asmacdo: 1 issues left to triage: 4987 15:31:47 #topic https://pulp.plan.io/issues/4987 15:31:48 RM 4987 - jcabrera - NEW - Pulp 3 is not validating that all required fields are being supplied to the RPM create API 15:31:48 #info ggainey has joined triage 15:31:48 !here 15:31:49 https://pulp.plan.io/issues/4987 15:31:50 ggainey: ggainey has joined triage 15:31:57 #info dalley has joined triage 15:31:57 !here 15:31:57 dalley: dalley has joined triage 15:32:13 #info dawalker has joined triage 15:32:13 !here 15:32:13 dawalker: dawalker has joined triage 15:32:14 i am writing a comment about this one 15:32:17 skip 15:32:19 it's rpm 15:32:20 but we should accept and add to sprint 15:32:26 okk 15:32:29 sounds good 15:32:31 !skip 15:32:32 asmacdo: No issues to triage. 15:32:41 well, i swear there *was* an issue a minute ago 15:32:50 Open Floor ..... 15:32:51 yea, it was a story actually 15:32:55 I updated it 15:33:17 oh ok 15:33:25 yeah open floo 15:33:46 :) 15:34:01 *deafening silence* 15:34:15 daviddavis: did you want to talk about https://pulp.plan.io/issues/4981 15:34:46 we can if people want to 15:34:59 I think I originally brought up that requirement, but I don't think it's 3.0 requirement par-se 15:35:13 I marked it as 3.0 just in case 15:35:28 I figured it was easier to remove it later but I am fine with it not being 3.0 15:35:32 i'd like to have an endpoint for this, not a scheduled job 15:36:58 and users could hit the endpoint with cron if they want 15:36:58 asmacdo: that would make sense to me 15:36:59 should it be part of the orphan namespace in our api? 15:36:59 overall though I think it's too early since we don't have a user or stakeholder driving it's needs 15:37:03 just me saying 'maybe we should do this' 15:37:11 you are the stakeholder bmbouter 15:37:13 jk 15:37:30 well, if we "leak" bits, we should provide a way to clean them up 15:37:38 bmbouter is the dude with a steak! 15:37:47 true but with that argument could be applied to a lot of areas of the 3.0 launch 15:37:53 asmacdo: ^ 15:38:12 bmbouter: fair enough 15:38:27 i am still curious about the cut of steak bmbouter is holding 15:38:45 it's a stake (a wooden post) and not a steak 15:38:48 he's hunting vampires 15:38:49 asmacdo: are you saying that we should just ensure DELETE works w/ single uploads or as a filterset 15:38:49 bmbouter: vampire hunter, stake holder 15:38:56 dang daviddavis you beat me 15:39:04 * bmbouter gets the Chimichurri out 15:39:09 lol 15:39:13 mmm chimichurri 15:39:22 it must be almost lunch time 15:39:23 * bmbouter pours chimichurri over pulp 15:39:32 indeed 15:39:39 bmbouter: i is there a way to get a list of incomplete uploads? 15:39:53 if so, then the single upload DELETE would be sufficient for 3.0 IMO 15:39:55 daviddavis: what did you imagine w.r.t asmacod's quesiton? 15:39:58 if we don't introduce this cleanup now, would it be easy/possible to remove those incomplete chunked uploads later? 15:40:17 asmacdo: I think I agree that there needs to be some way for the user to cleanup otherwise it's probably not ok 15:40:36 asmacdo bmbouter we could add filtering to get a list of incomplete uplaods but currently I don't think there is a way 15:40:37 ttereshc: I think not and I believe that is asmacdo's concern 15:41:15 yeah, then I agree with the concern 15:41:23 me too 15:41:49 can ew just ensure that the actual upload story allows for a DELETE of an upload? 15:41:53 as a reoslution 15:42:01 whcih upload story? 15:42:02 yeah ... i think that's needed at the minimum 15:42:13 daviddavis: that chunked uploads story you wrote yesterday 15:42:22 dkliban: the parallel upload one? 15:42:32 https://pulp.plan.io/issues/4488 15:42:38 yes 15:42:39 https://pulp.plan.io/issues/4488 15:42:49 I don't think it should be part of this story 15:42:57 the delete? 15:43:01 yea 15:43:09 4488 = support for parallel uploads 15:43:14 it might be worth making the delete story blocked by 4488 15:43:28 if it's not part of it, then yes 15:43:34 i don't mind not making it part of it 15:43:54 4891 can be follow up work for 4488 15:44:09 it makes more sense to me to do it together because it sounds like we'll be in a state that people are uncomfortable with if say we release in between these two stories 15:44:28 I'm not sure I understand 15:44:41 ttereshc and asmacdo can you restate your concerns 15:44:52 if people do chunked uploads currently, they will have incomplete uploads 15:45:11 it seems like deleting uploads should be implemented regardless of whether we do parallel uploads 15:45:24 daviddavis: i'm just assuming that the current chunked uploads are going to change 15:45:51 they will but I think of parallel uploads and deleting uploads as two separate pieces of work 15:46:00 I'm just having trouble imaging them as one I guess 15:46:31 especially if we are going to use a different library, i figure theres a decent chance that the deletion could be changed too 15:46:53 I think we're just removing the library 15:47:09 ok, i dont feel strongly about blocking relationship 15:47:24 I think it's fine if they are separate stories as long as both go into ga 15:47:30 +1 15:47:37 that's my feeling too 15:47:43 what about RC 3? 15:47:49 that was the concern I heard was rc3 15:47:59 or interpreted, actually no one said rc3 15:48:23 it sounds like if we do parallel uploads, that wont change the nature of the cleanup problem 15:48:25 I'm good w/ whatever you all agree to w.r.t to the landing of these various things 15:48:45 asmacdo: correct 15:48:52 it sounds like delete should go into rc3 15:49:06 when is rc3? 15:49:07 since we don't provide an upgrade path from rc to ga, I think it's a non-blcoking issue for rc3 but nice-to-have one 15:49:16 +1 ttereshc 15:49:35 rc3 is in a week 15:49:39 right bmbouter ? 15:49:46 sounds good to me 15:49:48 I have issues with the python api bindings: `sync_response = fileremotes.remotes_file_file_sync(file_remote.href, repository_sync_data)` 15:50:00 what's the issue? 15:50:26 ttereshc: yes rc3 is slated for monday but is movable within next week 15:50:45 fileremotes is already an object, that is closely related to the file/remotes endpoint. 15:50:51 does someone have time to work on https://pulp.plan.io/issues/4981 by rc3? 15:51:04 I might be able to do it by monday. not sure. 15:51:14 it seems too much to prefix the `sync` action with `remotes_file_file` 15:51:23 daviddavis: it depends on when 4488 gets done 15:51:33 oh sorry I meant 4488 15:51:40 lol 15:52:01 daviddavis: i was hoping you would do it ... but if you can't, i will definitely work on it 15:52:11 x9c4: i agree that it is very verbose 15:52:18 Also it prevents generic programming when creating / updating resources (That is the real problem). 15:52:29 ^ ...,deleting 15:52:31 x9c4: what do you mean? 15:52:47 dkliban: I think I can do it by monday if I can get some help (eg PR reviews) 15:53:06 daviddavis, dkliban I will be glad to dig in, maybe tomorrow (but if it's in new state, then I'm not on it) 15:53:08 I'll file the upload delete story. I think it's different than https://pulp.plan.io/issues/4981 15:53:09 daviddavis: i plan on providing PR review ... but i plan to be out all day friday 15:53:27 thanks daviddavis 15:53:33 ok, hopefully rc3 gets moved back a day or two 15:53:47 anything else for open floor? 15:53:51 if I could get someone to groom https://pulp.plan.io/issues/4488 that'd be great 15:54:13 daviddavis, I struggle to understand how do you get old incomplete chunked uploads to remove later? 15:54:46 ttereshc: by date of creation 15:54:51 ttereshc: you can list the uploads and see if they are complete or not 15:54:54 and then delete them 15:54:55 dkliban: I cannot write a function, that accepts an api-object (like FileRemote, Repository, ...) and let it decide whether to call 'update' or 'create' on it. 15:55:49 Instead, i need to have a copy of that code for every single api-object. 15:56:01 x9c4: i see what you are saying 15:56:34 x9c4: the name of that function is derived from the Operation Id from the OpenAPI schema definition of that endpoint 15:57:09 #endmeeting 15:57:09 !end