14:30:22 #startmeeting Pulp Triage 2017-04-04 14:30:22 Meeting started Tue Apr 4 14:30:22 2017 UTC and is due to finish in 60 minutes. The chair is ttereshc. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:30:22 The meeting name has been set to 'pulp_triage_2017_04_04' 14:30:22 #info ttereshc has joined triage 14:30:22 ttereshc has joined triage 14:30:37 !here 14:30:37 #info jortel has joined triage 14:30:37 jortel has joined triage 14:31:11 !here 14:31:11 #info daviddavis has joined triage 14:31:12 daviddavis has joined triage 14:32:13 * ttereshc thinks we need one more dev 14:32:41 yea 14:33:15 mhrivnak, bmbouter?^ 14:33:25 sorry, I think I missed some history. 14:33:35 just reconnected because I wasn't seeing any activity. :) 14:33:36 would you like to participate intriage? 14:33:45 !here 14:33:45 #info mhrivnak has joined triage 14:33:45 mhrivnak has joined triage 14:33:49 !next 14:33:51 2 issues left to triage: 2689, 2691 14:33:51 #topic Don't use ssh connection sharing in rsync distributor - http://pulp.plan.io/issues/2689 14:33:52 Pulp Issue #2689 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:33:53 Don't use ssh connection sharing in rsync distributor - http://pulp.plan.io/issues/2689 14:33:53 !here 14:33:53 #info bmbouter has joined triage 14:33:53 bmbouter has joined triage 14:34:20 !propose accept 14:34:20 #idea Proposed for #2689: Leave the issue as-is, accepting its current state. 14:34:20 Proposed for #2689: Leave the issue as-is, accepting its current state. 14:34:26 easyfix? 14:34:35 I think so 14:34:35 yes, good point. 14:34:50 !accept 14:34:50 #agreed Leave the issue as-is, accepting its current state. 14:34:50 Current proposal accepted: Leave the issue as-is, accepting its current state. 14:34:52 1 issues left to triage: 2691 14:34:53 #topic Pulp should verify if source for link exists - http://pulp.plan.io/issues/2691 14:34:53 Pulp Issue #2691 [NEW] (unassigned) - Priority: Normal | Severity: Medium 14:34:54 Pulp should verify if source for link exists - http://pulp.plan.io/issues/2691 14:35:41 broken symlinks can exist in case of on_demand, right? 14:35:48 yes. 14:35:54 I think this issue is too broad to be accepted as is 14:36:02 I agree. 14:36:13 agreed 14:36:13 jluza 's suggestion is probably valid for immediate case 14:36:53 in pulp2 the symlink publising it's a plugin by plugin behavior right? 14:36:53 Perhaps he's getting at a question of: should publish validate that expected files are on disk? 14:37:30 !propose needinfo 14:37:30 #idea Proposed for #2691: This issue cannot be triaged without more info. 14:37:30 Proposed for #2691: This issue cannot be triaged without more info. 14:37:32 bmbouter, kinda? But not in a way that I think will necessarily change. 14:37:58 actually, I think the suggested solution is wrong. verification (when appropriate) is the responsibility of the publisher, not the util function. 14:38:07 mhrivnak, he just thinks pulp shouldn't produce invalid data when publish task finished successfully 14:38:30 I agree completely with that, but it's not specific enough for us to fix as written 14:38:59 if it's publishing broken symlinks when they are expected to work we need to understand how to reproduce it so we can fix it 14:39:07 so I would say this needs a reproducer 14:39:10 jluza, i see your point. 14:39:27 for me it does make sense to do fix in util method, if for some reason is there a situation where you don't like to validate source, you can add option for that 14:39:53 otherwise you would have to change every single occurrence of make_symlink in your codes 14:40:27 I think there's a reasonable discussion to be had of whether it's enough for a distributor/publisher to create references to content that should exist, or must it also validate that the content it references exists. 14:40:41 How paranoid should it be. 14:41:23 that all sounds good, but how would QE verify this without a reproducer? 14:41:31 Our users tend to be performance sensitive, particularly with regard to publishing, so verifying the presence of files is something we haven't added to that workflow. 14:42:33 it can possibly be an option and users will be aware that it can slow things down 14:42:35 I could see this as an RFE to verify the presence of files during publish, and then we could discuss its value. 14:42:47 I see there's question of quality vs quantity 14:42:58 I don't see this as a bug. 14:43:37 ttereshc, you mean in [server] section: paranoid = True ? 14:44:04 jluza: yea that's one option. or perhaps on the publisher? 14:44:20 yep, Ithought more about publisher 14:44:36 jluza, what do you think about changing it to story? 14:44:39 but if this feature compensates for a defect then we should fix the defect 14:44:44 Validation of content on disk in general is something a lot of people are interested in being able to do. 14:44:52 I'm not sure publish is the right time to do it. 14:45:04 agreed 14:45:14 can we turn it into a story and continue discussion on the bug? 14:45:23 yes, let's do that 14:45:31 mhrivnak, what should be good time then? 14:45:34 +1 14:45:39 !propose other convert to story 14:45:39 #idea Proposed for #2691: convert to story 14:45:40 Proposed for #2691: convert to story 14:45:40 jluza, sync 14:45:51 or "download_repo" task 14:45:54 mhrivnak, yeah, I already filled another story for that 14:45:55 or some new task we don't have yet. 14:46:06 mhrivnak, hmm actually Ina did that, but we discussed that 14:47:44 jluza, do you have link handy? 14:47:51 I can't find it 14:48:21 mhrivnak, so we will convert this bug to story or close it if it is a dup 14:48:23 ok? 14:48:27 ttereshc, https://pulp.plan.io/issues/2624 14:48:29 Title: Story #2624: As a user, I can verify blobs checksum during sync - Docker Support - Pulp (at pulp.plan.io) 14:48:33 Either is fine with me. 14:48:44 #agreed convert to story 14:48:45 !accept 14:48:45 Current proposal accepted: convert to story 14:48:47 No issues to triage. 14:48:56 !end 14:48:56 #endmeeting