14:33:32 #startmeeting Pulp Triage 2020-06-26 14:33:32 !start 14:33:32 Meeting started Fri Jun 26 14:33:32 2020 UTC. The chair is daviddavis. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:33:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:33:32 The meeting name has been set to 'pulp_triage_2020-06-26' 14:33:32 #info daviddavis has joined triage 14:33:41 #info dkliban has joined triage 14:33:41 !here 14:33:42 #info ggainey has joined triage 14:33:42 !here 14:33:42 #info ppicka has joined triage 14:33:42 !here 14:33:47 #info x9c4 has joined triage 14:33:47 !here 14:33:50 !next 14:33:50 #topic https://pulp.plan.io/issues/7047 14:33:57 hmm 14:33:58 #info ttereshc has joined triage 14:33:58 !here 14:33:59 daviddavis: daviddavis has joined triage 14:34:00 dkliban: dkliban has joined triage 14:34:01 ggainey: ggainey has joined triage 14:34:02 ppicka: ppicka has joined triage 14:34:03 lol 14:34:04 x9c4: x9c4 has joined triage 14:34:05 daviddavis: 4 issues left to triage: 7047, 7045, 7019, 7003 14:34:06 RM 7047 - hyu - NEW - Checksum type "sha256" is not available for all units in the repository. Make sure those units have been downloaded 14:34:07 https://pulp.plan.io/issues/7047 14:34:08 catching up 14:34:09 ttereshc: ttereshc has joined triage 14:34:15 move to rpm? 14:34:24 yes 14:34:25 #idea Proposed for #7047: move to rpm 14:34:25 !propose other move to rpm 14:34:25 daviddavis: Proposed for #7047: move to rpm 14:34:26 yes 14:34:34 #agreed move to rpm 14:34:34 !accept 14:34:34 daviddavis: Current proposal accepted: move to rpm 14:34:35 #topic https://pulp.plan.io/issues/7045 14:34:35 daviddavis: 3 issues left to triage: 7045, 7019, 7003 14:34:36 RM 7045 - bmbouter - NEW - Plugin Writer API Reference is out of date 14:34:37 https://pulp.plan.io/issues/7045 14:34:58 !propose accept and add to sprint? 14:34:58 dkliban: propose accept Propose accepting the current issue in its current state. 14:35:10 oops 14:35:19 do we want to add to sprint? 14:35:27 heh 14:35:49 we can, before miniteam decide which to drop 14:35:56 *miniteams 14:36:01 ok! 14:36:10 #idea Proposed for #7045: accept and add to sprint 14:36:10 !propose other accept and add to sprint 14:36:10 dkliban: Proposed for #7045: accept and add to sprint 14:36:15 +1 14:36:20 +1 14:36:32 #agreed accept and add to sprint 14:36:32 !accept 14:36:32 daviddavis: Current proposal accepted: accept and add to sprint 14:36:33 daviddavis: An error has occurred and has been logged. Please contact this bot's administrator for more information. 14:36:43 :o 14:36:50 !next 14:36:50 #topic https://pulp.plan.io/issues/7019 14:36:51 daviddavis: 2 issues left to triage: 7019, 7003 14:36:52 RM 7019 - wibbit - NEW - Failure Syncing Against Remote Repository / Update docs 14:36:53 https://pulp.plan.io/issues/7019 14:36:56 #info bmbouter has joined triage 14:36:56 !here 14:37:14 ah, that's the "call out utf8 as a db-req" issue 14:37:19 yep 14:37:23 dind't we triage this already? 14:37:24 this should be a docs issue 14:37:32 it was in rpm meeting 14:37:37 oh 14:37:38 yes we move it to pulp as docs 14:37:47 accept and add docs tag? 14:37:48 add docs tag 14:37:49 +1 14:37:50 #idea Proposed for #7019: accept and add docs tag 14:37:50 !propose other accept and add docs tag 14:37:50 dkliban: Proposed for #7019: accept and add docs tag 14:37:51 +1 14:37:52 +1 14:37:54 +1 14:37:57 #agreed accept and add docs tag 14:37:57 !accept 14:37:57 daviddavis: Current proposal accepted: accept and add docs tag 14:37:57 +1 14:37:58 #topic https://pulp.plan.io/issues/7003 14:37:58 +1 14:37:58 daviddavis: 1 issues left to triage: 7003 14:37:59 RM 7003 - dkliban@redhat.com - NEW - pulpcore-content allows for // in some parts of the URL but not others 14:38:00 https://pulp.plan.io/issues/7003 14:38:14 i am going to add this item to open floor now 14:38:31 it's our last issue so we can just discuss? or do you want to come back to it? 14:38:45 let's discuss 14:38:58 i would like the content app to treat all // as / 14:39:13 that's fine with me. as long as we're consistent. 14:39:17 concur 14:39:21 bmbouter: ? 14:39:23 agree 14:39:44 +1 14:39:50 is there a django-way to 'normalize' incoming uris? 14:39:56 can we filter incoming urls through some normalizer? 14:40:05 yeah let's discuss 14:40:07 that could be applied at a gateway/gatekeeper point? 14:40:15 x9c4: yeah that :) 14:40:21 ggainey, you took the words right out of my keyboard. 14:40:24 hehehe 14:40:39 the content app is not a django app 14:40:42 I think treating // as / is probably fine 14:40:49 dkliban: oh right 14:40:51 I need a min or two more to think/test about it but at first take yes 14:41:07 however, we could use django facilities if needed 14:41:21 not requiring the trailing slash would also be nice. 14:41:40 just doing some quick testing some of the big web services yield 404 when you replace / with // 14:42:03 we can discuss at open floor more tho would probably be good rather than right now 14:42:15 some redirect you though 14:42:28 ok ... i'll add it to the end of the agenda 14:42:43 kk 14:42:56 !next 14:42:57 daviddavis: No issues to triage. 14:43:06 Open floor! 14:43:20 Topic: Should we stop automatically requesting QE to review PRs with changed tests? 14:43:40 I think so, I can file an issue 14:43:40 yes 14:43:42 +1 14:43:48 +1 14:43:51 yeah, concur 14:43:55 +1 14:44:10 great, thanks 14:44:22 Topic: When do we want to do the 3.5 release of pulpcore? 14:44:23 I just noticed that they are pinged almost on every PR 14:44:28 yea it's annoying 14:44:29 yupyup 14:44:32 yup 14:45:04 are we still doing time-based releases of pulp 3? 14:45:07 3.4 went out on June 2 14:45:16 i was hoping we could do a time based release 14:45:32 and that we could do a faster than normal 3.6 release 14:45:33 daviddavis: iirc the goal was once-a-month/every-6-weeks, with whatever was ready 14:45:33 yes I think we should 14:45:49 ggainey: I also remember roughly that 14:45:49 and I am good w/that, lots of good stuff happening 14:45:59 +1 14:46:01 unless 3.5 will have the RBAC tech preview in this short time remaining 14:46:17 our 3.4 release was May 27th 14:46:25 so we're just at 1 month tomorrow 14:46:46 who wants to release tomorrow? 14:46:48 heh 14:46:54 jk 14:46:57 daviddavis: i was thinking next week 14:47:05 on tuesday or wednesday 14:47:15 I'm ok w/ that I can have the tech preview of rbac in by then 14:47:16 that's cool, the only thing I worry about is the holiday 14:47:19 oh eah 14:47:25 if we can't do it tues/weds, we should wait - lots of folk out fri/mon 14:47:31 yea 14:47:31 yep 14:47:57 the other thing about releasing, is y'all have done so much good work on the release process it seems to become less and less painful every release 14:48:11 it's true but it's still quite painful 14:48:12 so releasing-often is good because it continues to squeeze friction out of the process 14:48:19 that's true 14:48:29 i would like to send an email to pulp-dev today announcing that we want to do a release of pulpcore on tuesday 14:48:40 if we need to push it to wedensday we should announce that on tuesday 14:48:54 we probably won't have any more release automation by then 14:48:56 just fyi 14:49:02 heh 14:49:03 that's ok 14:49:06 ok 14:49:16 july 7th and we could get some more release automation done 14:49:29 +1 july 7th 14:49:35 hm, that's a good point 14:49:38 we don't have a strong time based driver for next week 14:49:44 I should have kickstarts merged by then too 14:49:52 which has some core changes 14:49:53 also, that would be start-of-week, instead of trying to squeeze it in before holidays 14:49:57 yup 14:49:58 +1 to test new release automation on july 7th 14:50:03 also plugin releases, there will be many 14:50:14 yeah, +1 to the 7th 14:50:28 ipanova and I are out that week though, speaking about plugin releases 14:50:33 also, ttereshc will be out that week, so she knows she won't get stuck w/it :) 14:50:36 heh, gmta 14:51:01 that shouldn't be a big deal 14:51:06 +1 to july 7th 14:51:15 not a big deal, just fyi 14:51:44 cool, anything else to discuss for the 3.5 release before we move on to our last topic? 14:51:48 so - send an announcement today, for the 7th? 14:51:51 ttereshc: i can do the RPM release 14:52:00 dkliban: you do the container and I'll handle rpm 14:52:06 sounds good 14:52:25 sweeet 14:52:26 can I watch one/both of you go through this on the day? 14:52:32 ggainey: yes 14:52:35 awesome 14:52:39 I'll be streaming it on twitch 14:52:41 jk 14:52:44 ha! perfect! 14:52:46 ggainey, you can actually do it instead of watching :P just saying 14:52:46 maybe you should 14:52:48 oh I hoped you were serious 14:52:52 lol 14:53:06 i'll get my green screen ready for that 14:53:11 so i can stream myself doing it 14:53:18 :) 14:53:22 ttereshc: dkliban: daviddavis: hm, not a bad idea, we can talk about who gets to/has to push the actual buttons closer to the day 14:53:31 +1 14:53:51 alright ... i'll send out the announcement to pulp-dev 14:53:55 coolio 14:53:55 great thanks dkliban 14:54:01 thanks! 14:54:21 Topic: Content app treatment of "//" in URLs - https://pulp.plan.io/issues/7003 14:55:15 so what is driving this is my question aka what forms urls like /pulp/content/centos8/AppStream//repodata/repomd.xml returns 404 14:55:15 bmbouter dkliban ^ 14:55:18 github.org lets you put // in the URl and it responds with content 14:55:26 yup and google does not 14:55:36 youtube.com redirects you to the / 14:55:43 drive does not 14:55:55 so, amusingly, the w3.org page for the http-protocol-rfc allows // : https://www.w3.org/Protocols/rfc2616//rfc2616.html :) 14:55:57 let's step back from the precident game for a second 14:56:12 I'm trying to see if the RFC makes a declarative stmt 14:56:21 ggainey: does the BNF support it? 14:56:28 s'what I'm looking into 14:56:34 excellentay 14:57:04 If we allow for "//" its easier to create api urls in shell-scripts without too much thinking. 14:57:08 while that's being looked at can we chat for a second about the use case forming these urls? like for example is anaconda forming it, is our redirect code forming it? 14:57:31 yeah ... anaconda is forming these URLs sometimes 14:57:52 also, me when I mistype urls 14:57:57 lol 14:58:17 I agree it's convenient 14:58:26 but is it right per the standards 14:58:31 I think it might happen in our code during sync, in rpm 14:58:51 when the user specifies the URL for a remote with a / on the end 14:58:55 or sometimes now 14:58:58 not 14:58:59 ah we are talking about content-app 14:59:11 ttereshc: yes, but what if pulp is syncing from pulp 14:59:21 it will be talking to the content app 14:59:29 hmm, true :) 14:59:51 typical smart proxy scenario ^ 14:59:58 yep 15:00:01 yup 15:01:33 so right now this would work fine 15:01:49 the internet seems pretty conflicted on this 15:01:50 ok, so the standard (https://www.ietf.org/rfc/rfc2396.txt) says "The path may consist of a sequence of path segments separated by a single slash "/" character." - HOWEVER - the internet in general, and HTTP in particualr, has always been "be permissive in what you accept and rigourous in what you send" 15:02:09 as you can seee in the ticket i filed, if you add an extra / after the base_path, the current behavior of the content-app gives a 200 repsonse 15:02:37 aceepting // in abs_paths isn't 'standard', but it does recognize that HTTP URLs come from people, who are Terrible At This, and can be easily normalized 15:02:58 I feel personally attacked 15:02:59 dkliban: so your observation is that we're inconsistent not that we don't already support // 15:03:15 bmbouter: yes, exactly 15:03:27 and i want consistency 15:03:43 one way or another 15:03:44 yeah, that's the bigger thing to me as well, honestly 15:03:45 the only question is which way 15:03:50 whatever we do, do that One Thing 15:03:56 yep 15:04:20 is one way easier than the other? 15:04:22 so the thing is that is going to be tough to achieve 15:04:29 my personal pref would be "clean up incoming URLs, always" - but the 'always' is the important thing 15:04:56 plugins ship their own urls for both the content app and django 15:04:57 i agree 15:05:22 and the regex for django for example, is not going to match // as / without care taken everywhere 15:05:36 yep 15:05:42 I agree w/ the One Way btw, I'm just pointing out the difficulty of getting there 15:05:57 Maybe that would result in a urlrewrite in apache / nginx ? 15:06:06 is there a pre-django Thing we could do? so that by the time django sees the abs_path, it's already been 'cleaned'? 15:06:06 I think that is the only actual way 15:06:14 nginx and apache could handle this 15:06:18 ok, I think we're all on the same page here 15:06:25 yep 15:06:36 i was also thinking we would use nginx/apache to solve the problem 15:06:42 something like this https://www.mydigitallife.net/redirect-or-rewrite-to-remove-double-or-multiple-slashes-in-url/ 15:06:51 ype 15:07:02 This means in pulplift dev we would not solve it. 15:07:03 and this would be in our documentation and in the installer 15:07:13 the installer itself would be solving it 15:07:28 because it carries the nginx and apche reverse proxy configs 15:07:33 ah 15:07:33 yep 15:08:04 so update the issue saying we should update the installer and docs to have nginx/apache handle double slashes? 15:08:13 and the dev installation has no reverse proxy. 15:08:13 yeah, I like that 15:08:21 (re update-issue) 15:08:21 x9c4: it does 15:08:26 all installs do 15:08:28 yea I use it 15:08:32 then i have a very old one... 15:08:33 not everyone chooses to use it 15:08:44 it would have to be mid-2019 old 15:09:03 if I am hitting pulp on port 80, that's through nginx right 15:09:08 yes 15:09:16 and soon port 443... :) 15:09:20 :O 15:09:22 that only means i need to revisit it. 15:09:39 x9c4: but you use pulplift right? 15:09:44 yes. 15:09:54 then you're receiving it 15:10:09 do we accept this issue or accept + add it to the sprint? 15:10:15 +1 15:10:18 +! 15:10:25 I want to ask: so we're ok w/ applications never being able to match // ? 15:10:31 because with this rewrite rule they never could 15:10:39 yes 15:10:41 bmbouter: you mean deliberately? 15:10:43 yes 15:10:43 I can't think of a reason why but just asking 15:10:46 yes deliberately 15:10:58 bmbouter: yes, because the spec says that they shouldn't 15:11:01 that would be *deliberately* violating the HTTP spec, which would be Bad 15:11:05 zacly 15:11:09 Having a need for this sounds like very bad design. 15:11:11 my reading claims it's valid 15:11:14 in the spec 15:11:17 oh 15:11:25 The path may consist of a sequence of path segments separated by a 15:11:25 single slash "/" character. 15:11:39 straight from the 'path component' section of https://www.ietf.org/rfc/rfc2396.txt 15:11:44 can a path segment be ""? 15:12:21 it can be is what I'm reading 15:12:38 interesting 15:12:38 but I don't think that's a good URL design regardless 15:13:01 and I am in favor of the redirect // to / by default globally in nginx and apache 15:13:05 but to be clear it's a valid url 15:13:18 that is distince from it's single slash counterpart 15:13:19 yep 15:13:26 distinct 15:14:05 we will need to add docs around base_paths not being able to contain // 15:14:18 oh yeah and a validation there 15:14:24 yes 15:14:25 I'm not sure I agree it's 'legal' by the BNF, but will cheerfully admit it's been a Really Long Time since I could relilably read BNF :) 15:14:26 and likely a migration rule 15:14:45 bmbouter: a migration rule? docs? 15:15:33 sorry I'm not being clear, I meant a migration to rewrite base_paths with // to / 15:15:53 if we make this change and don't provide that migration any (rare of course) places where // is in a base path would start to 404 15:16:12 this is a very rare case 15:16:30 I'm ok just doc-ing it because we'd have to ship a migration for every plugin it just doesn't seem worth it 15:16:44 yep 15:16:55 i don't want to ship a migration for every plugin 15:16:55 yeah, that sounds good to me 15:16:59 me neither 15:17:11 cool. i'll summarize all this on the issue 15:17:25 (also, I think bmbouter is correct, I missed a '*' in the BNF that implies a path-segment could be empty) 15:17:32 coolio 15:17:35 +1 all around 15:17:52 ggainey: BNF is confusing 15:17:55 !friday 15:17:55 ♪ It's Friday, Friday, gotta get down on Friday ♪ 15:18:07 :) 15:18:08 dkliban: will this beocme an installer issue? 15:18:12 i rely on you all to read it and provide cliff notes for me 15:18:16 bmbouter: I used to think in this stuff when I was doin compilers for a living - but, it has been A Hot Minute, as You Kids say these days :) 15:18:19 dkliban: I can re-read if you send it to me 15:18:41 bmbouter: yes, i can also create a separate docs isssue 15:18:59 +1 15:19:03 subtasks? 15:19:05 yes 15:19:13 all that 15:19:32 sweet, ty 15:19:38 ok, anything else for open floor? 15:20:10 last calls 15:20:12 call 15:20:21 !friday 15:20:21 ♪ It's Friday, Friday, gotta get down on Friday ♪ 15:20:29 #endmeeting 15:20:29 !end