14:29:48 #startmeeting Pulp Triage 2019-08-09 14:29:48 #info asmacdo has joined triage 14:29:48 !start 14:29:48 Meeting started Fri Aug 9 14:29:48 2019 UTC. The chair is asmacdo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:29:48 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:29:48 The meeting name has been set to 'pulp_triage_2019-08-09' 14:29:48 asmacdo: asmacdo has joined triage 14:29:58 #info dkliban has joined triage 14:29:58 !here 14:29:58 dkliban: dkliban has joined triage 14:30:06 #info daviddavis has joined triage 14:30:06 !here 14:30:06 daviddavis: daviddavis has joined triage 14:30:24 #info dawalker has joined triage 14:30:24 !here 14:30:24 dawalker: dawalker has joined triage 14:30:29 !next 14:30:30 #topic https://pulp.plan.io/issues/5233 14:30:30 asmacdo: 1 issues left to triage: 5233 14:30:31 RM 5233 - dkliban@redhat.com - NEW - pulplift box does not restart pulp-worker@0 14:30:32 https://pulp.plan.io/issues/5233 14:30:35 #info fabricioo0 has joined triage 14:30:35 !here 14:30:35 fabricioo0: fabricioo0 has joined triage 14:31:03 yeah ... my boxes alwyas have a pulp-worker@0 14:31:07 at the moment there is no such thing as pulp-worker@0 unless you manually restart it AFAIK 14:31:24 but there is a systemd unit file for it 14:31:47 I don't have a systemd unit file for it 14:31:54 oh ok 14:31:56 me neither 14:32:15 #info bmbouter has joined triage 14:32:15 !here 14:32:15 bmbouter: bmbouter has joined triage 14:32:19 they're defined here https://github.com/pulp/ansible-pulp/tree/master/roles/pulp-workers/templates 14:32:20 #info ipanova has joined triage 14:32:20 !here 14:32:20 ipanova: ipanova has joined triage 14:32:23 based on what's in the settings 14:32:34 it probably does make more sense to start with 0 though 14:32:43 #info ttereshc has joined triage 14:32:43 !here 14:32:43 ttereshc: ttereshc has joined triage 14:32:54 and we could update the function to work with pulp-worker* 14:33:19 I agree it makes sense from 0 14:33:38 yeah ... i guess i'll update the issue 14:33:40 hardcoding the number of workers has always semibothered me 14:33:49 it's not hardcoded now 14:33:55 it is 14:34:15 the systemdfile is a template so it couldn't be 14:34:17 https://git.io/fj7Wo 14:34:19 it will accept any number 14:34:26 oh I meant prestart is hardcoded 14:34:30 hardcodeing isnt the right word 14:34:30 https://github.com/pulp/ansible-pulp/blob/master/roles/pulp-workers/defaults/main.yml#L2-L8 14:34:49 i think the only thing that should be a var is the number of pulp workers 14:35:00 not a dict for each one 14:35:04 this seems really low priority IMO 14:35:09 agreed 14:35:20 and we've got tons of much higher priority stuff 14:35:22 agreed, the concern was that workers weren't being restarted let's go back to that 14:35:53 my bet is that dkliban did `systemctl restart pulp-worker@0` sometime 14:36:00 yeah 14:36:02 definitely 14:36:11 if prestart, restarts all running workers then I think we're good as is 14:36:16 so i think the main thing i want to get out fo this is that we change pulplift 14:36:34 to do what? 14:36:44 i want prestart to actually restart all running workers .... or at least start with the one numbered 0 14:37:34 in the dev environment, it does restart all workers and there is no worker 0 though 14:39:08 daviddavis: ok ... can we change that? i want worker 0 and 1 14:39:15 cause that's what we had in pulp 2 14:39:26 that's fine but it should probably be a task then 14:39:35 agreed, sounds fine, +1 task 14:40:02 +1 14:40:04 also we probably shouldn't hardcode the worker numbers in https://git.io/fj7Wo 14:40:19 daviddavis: i was thinking about that 14:40:22 maybe that can be part of this task 14:40:25 yep 14:40:29 im not sure how it would behave for "start" 14:40:42 since its a template, how would it know how many to start? 14:41:05 pulp-worker* would work fine for restart 14:41:11 maybe it could check /etc/systemd/system/multi-user.target.wants/pulp-worker* ? 14:42:02 ok so i guess we update the issue to rename the workers 0 and 1, and optionally to look into making prestart more flexible 14:42:28 +1 14:42:35 and convert to task 14:42:48 +1 14:43:10 #idea Proposed for #5233: asmacdo will convert to task, revise description 14:43:10 !propose other asmacdo will convert to task, revise description 14:43:10 asmacdo: Proposed for #5233: asmacdo will convert to task, revise description 14:43:38 #agreed asmacdo will convert to task, revise description 14:43:38 !accept 14:43:38 asmacdo: Current proposal accepted: asmacdo will convert to task, revise description 14:43:39 asmacdo: No issues to triage. 14:43:55 open floor 14:44:05 !issue 4983 14:44:05 #topic https://pulp.plan.io/issues/4983 14:44:06 RM 4983 - bmbouter - NEW - Add changelog check to the Travis configuration tool 14:44:07 https://pulp.plan.io/issues/4983 14:44:21 I added a check here but it's annoying 14:44:39 it just checks for a file in CHANGES/ if there's an issue on the commit 14:44:53 yeah so we should do the rest of this soon 14:45:04 +1. we can add it to the sprint I think. 14:45:07 but i do have a thought 14:45:23 i am not entirely convinced we need to be quite as strict as described in the issue 14:45:31 for instance, lets say we add a new feature 14:45:34 daviddavis: when you say it's annoying what do you mean? 14:45:43 (it's nagware so annoying I think is by design) 14:45:47 then we discover a bug in the new feature, file a story and fix it 14:45:55 bmbouter: haha +1 14:46:00 do we really want that to show up in the changelog? 14:46:34 I think so. you could add a XXXX.misc entry if you really don't want to. 14:46:45 asmacdo I think part of the strategy is to keep related commits on 1 ticket 14:47:07 if it was never released then the CHANGES is still there so the second PR would see there is already an entry for that 14:47:16 if it's been released then a new ticket would also desire a new changelog 14:47:28 yeah this was only if not released 14:47:41 so the thing to do would be to reopen the original issue 14:47:57 you shouldn't have to reopen the issue if it's not released 14:48:22 if it's released, then I think you should file a new bug 14:48:35 this is also how I imagined it 14:48:46 how do we track that kind of work then? 14:49:10 if you're touching up work in MODIFIED then use the existing commit 14:49:30 bmbouter: i think that only works in the case that whoever fixes the problem does so immediately and just remembers to do the work 14:49:54 unfinished work (IMO) should always have an open issue 14:52:05 hows this for a compromise 14:52:31 no matter the type of the issue, also check for a .misc 14:52:51 that way we can use the issue tracker however we feel is most appropriate 14:53:15 and if we dont want it to show up as a userfacing release note, make it .misc 14:54:03 that sounds good to me although it sounds like the opposite of what you were arguing for 14:54:54 heres the requirements that are important to me: open issue for all work that needs to be done 14:55:41 ability to use the changelog flexibly, without being forced to include things that we dont think sohuld be user facing 14:55:45 so basically we update 4983 to always check for a CHANGES file if there's an issue on the commit? 14:56:11 the story was designed to make changelog entries a requirement so this proposal deviates from my goal 14:56:35 but maybe what daviddavis put in place is already doing that? 14:56:46 yea I think so 14:56:52 I'd like to come back to the original idea of what we want that we don't already have 14:57:20 suppose this 14:57:26 there's a feature 1234 and it's done 14:57:30 but not released 14:57:43 I want to fix a bug and add 1234.bug 14:58:00 actually that will work with the proposal in 4983 14:58:10 because there should be a 1234.story 14:58:24 or 1234.feature (I can't remember the ext) 14:58:28 feature 14:58:31 yup 14:58:35 daviddavis: but then the changelog would say to users: this release gives you this feature, and fixes it 14:58:54 asmacdo: well, you could specify in 1234.bug what the fix is 14:59:12 I agree w/ you asmacdo 14:59:17 yeah, but as far as the user is concerned, i think that would be more confusing than anything else 14:59:22 agreed 14:59:27 so i think the bugfix for 1234 should be 1234.misc 14:59:32 daviddavis: I can see what you're saying but I think it's confusing 14:59:44 how so? 14:59:47 I thikn the idea is there could be no CHANGES entry at all becasue 1234.feature already exists 15:00:09 daviddavis: it's confugisng to users because the changelog cites a bugfix that 100% of end users never had 15:00:35 yeah 15:00:44 I unfortuately have to drop for a meeting 15:00:46 I don't see how 4983 requires a XXXX.bug file 15:00:57 maybe I am missing something 15:01:14 daviddavis: i think we should feel free to open bugs against new features that havent been released yet 15:01:26 and then fix them citing the new bug, and not the original feature 15:01:34 asmacdo: ok how does 4983 prevent that? 15:02:12 becuase if we cite the new bug, then its an issue and requires a bugfix changelog, which shouldnt be shown to users because they never experienced that bug 15:02:29 ah I see 15:03:09 but if we expanded the requirements of 4983 to check for either whats listed there now OR .misc, i think we have full control 15:04:16 want me to write that up? 15:04:28 let's maybe discuss on teh issue 15:04:37 I'm not convinced we shouldn't show feature fixes in changelog 15:05:00 ack 15:06:11 alright I have to go to a meeting 15:10:28 daviddavis: https://pulp.plan.io/issues/4983#note-2 15:11:30 asmacdo: tested https://pulp.plan.io/issues/4549 , the step that took 100+sec before, down to 1.5sec :) nice work 15:11:56 \o/ 15:12:01 ty mccun934 15:12:37 asmacdo++ 15:12:37 ggainey: asmacdo's karma is now 130 15:22:10 asmacdo: https://pulp.plan.io/issues/4983#note-3 15:22:58 daviddavis: are you considering a .misc as not being a changelog entry? 15:23:36 yes 15:26:08 daviddavis: i dont think i see what you mean 15:26:27 daviddavis: if it should be a changelog entry, the dev would not use .misc 15:26:57 the nagware cant really make sure we do it right, but it can enforce that we dont forget. I think thats enough 15:32:44 asmacdo: I think we continue to use what we have currently 15:33:10 and tasks should have CHANGES/ files too 15:33:45 does that make sense? 15:33:53 so we dont make any assumptions about what type of change there is, just that there is a change 15:34:06 yes 15:34:09 yeah thats ok with me 15:34:24 :) took me a while to come around to it, but i agree 15:34:33 thanks for being patient daviddavis 15:34:40 asmacdo: ha you too 15:35:09 daviddavis: im going to close as MODIFIED with a comment 15:36:41 ok cool 15:39:09 * asmacdo is going AFK to refresh my machine 16:16:14 ttereshc: here is the update for pulplift so that it will include the latest ansible-pulp module https://github.com/pulp/pulplift/pull/42 16:25:36 dawalker, fyi ^ 16:26:11 ty ttereshc and ty dkliban 16:26:44 ah though it might be only relevant for the new box, we'll see :) 16:27:07 dkliban, merge 16:27:27 ttereshc: it's only relevant for the new box 16:27:38 ok 19:40:49 So our systemd service is called "pulp-content-app", but the script on disk and my container is named `pulp-content`. 19:41:09 Do we have a preference for one name or the other? 20:04:44 hmm 20:05:01 we should definitely be consistent 20:06:45 Yeah. This has been bugging me for about a month. I'm just about to put the container name in the travis script.sh. 20:07:11 I know there are aliases or whatever to handle systemd renaming properly. 20:07:14 i prefer the shorter name actually 20:07:23 My vote would be pulp-content because it's shorter and still clear. 20:07:44 maybe we should bring up on pulp-dev list? 20:08:07 Agreed. I'll bring it up next week during DevConf.US. 20:12:35 mikedep333: would it make sense to have pulp-smash config have the pod name for the pulp-api? 20:13:24 mikedep333: i see a pretty simple way to add kubectl transport for pulp-smash client object 20:13:35 what i want to avoid is searching for the pod 20:13:56 It changes. Not sure how often. 20:14:01 For CI purposes, that's fine though. 20:14:49 *not sure when it changes. I re-deploy the containers so often I wouldn't notice if it changed due to say host reboot. 20:15:04 i think it changes every time you deploy the container 20:15:31 Yes. Which is something we do all the time during development, not sure during usage. Like an upgrade usage scenario. 20:17:16 You could just make the field be called "pod-name" or something, and we could look into alternate IDs later. 20:19:28 mikedep333: ok ... for right now i am going to search for it the name 20:19:53 +1 20:23:42 mikedep333: i gotta run for now. let's touch base on monday morning. 20:23:44 dkliban++ 20:23:46 mikedep333: dkliban's karma is now 344 20:23:53 Thank you for all the video call advice today. 20:24:23 you are welcome ... thanks for all your work toward the container effort 20:24:29 mikedep333++ 20:24:29 dkliban: mikedep333's karma is now 21 20:25:58 You're welcome! 13:49:42 btw i chuckled to see that LGTM is translated to "lets get this merged" 13:49:50 same 13:50:56 ha! 13:53:00 kersom: rochacbruno: bherring: i would like to file an issue for the work that mikedep333 just mentioned. i would like to add another transport type for the 'shell' client: https://github.com/PulpQE/pulp-smash/blob/master/pulp_smash/cli.py#L135 13:53:20 where should i file this ticket? in github or pulp.plan.io ? ... i plan on implementing this today 13:53:34 the new transport type will be called 'kubectl' 13:53:51 pulp smash githug 13:53:54 k 13:54:12 https://github.com/PulpQE/pulp-smash/issues 13:54:29 githug - the new, kinder, gentler github 13:54:34 k ... i'll share a link once i've written it up 13:54:37 lol 13:54:49 ha! 13:54:57 just noticed now 13:55:10 dkliban, thanks 13:56:15 we do have a few tests failing for our internal CI for pulp 3, a few of them related to the RPM plugin, I will verify them locally today, and update here. We are currently using F29 as base OS. 14:07:40 kersom: rochacbruno: bherring: https://github.com/PulpQE/pulp-smash/issues/1214 14:08:30 ack. 14:42:51 fabricioo0: https://github.com/pulp/pulp_file/pull/269#discussion_r312905389 14:59:52 asmacdo I just followed the way it was on docs, I didn't think about the format 15:05:50 I see. fabricioo0 it's minor enough to probably not be worth changing everywhere-- I'm curious if Django needs that or if they could use a docs update 15:07:21 I'm curious also, I will change to f-string and check if everything works 15:12:39 the linter just showed me why: https://i.imgur.com/iNKLx59.png 15:13:35 aha! TIL 15:15:30 I guess that's actually some Django majic going on under the hoodd 15:15:39 magic* 15:19:04 I'm coming from pyramid, I think almost everything in django is magic, haha 15:40:07 Hi guys, would you mind to take a look at my stale PRs? 15:40:11 https://github.com/pulp/pulpcore/pull/229 15:40:16 https://github.com/pulp/pulpcore/pull/235 15:40:20 https://github.com/pulp/pulpcore/pull/257 15:40:59 please leave some comments if you find any issues; I have to go home now; later :) 07:36:17 Hello ! 07:39:26 I have a little question for you guys. I would like to use pulp to replace my spacewalk solution. I've stumbled upon a k8s-pulp image on docker hub but the last commit is from 2 years ago. 07:39:54 Has it been abandonned or is it still possible to make pulp running using k8s? 08:44:10 Leylan: There is currently work for pulp3 to run on K8s, but it’s not production ready yet 08:47:38 Good to know ! 08:48:50 Is there a github project where i could see how the advancement is going and trying to try it by my own or is it far to soon right now 12:20:16 Leylan: https://github.com/pulp/pulp-operator/ 12:23:21 thank you ! 12:25:58 Leylan: this is a very active effort ... our goal is to publish containers with every PR merged ... that will be the latest ... and we will also publish containers with every release 12:33:02 jsherrill: can you take a look at https://travis-ci.com/pulp/pulpcore/jobs/224539676#L1737 ? this is output for the improved content_summary in the bindings ... the previous output can be found at the end of the issue description here https://travis-ci.com/pulp/pulpcore/jobs/224539676#L1737 12:33:13 oops ... here is the issue https://pulp.plan.io/issues/5210 12:38:30 btw, I’m back „online“, but have to very carefully manage my team spent on keyboards due to RSI reasons 12:41:12 welcome back morre 12:46:40 dkliban: so it looks like the 'outer' hash is correctly serialized, but the 'inner hash' is now still an escaped string 12:47:07 {"added"=>"{:\"file.file\"= 12:47:35 actually maybe not 12:47:52 oh yeah it is 12:48:04 notice the starting quote after the hash rocket 12:48:16 "{:\"file.file\" thats a string, when it should be a hash 12:56:31 yeah 12:57:07 fabricioo0: jsherrill and i just starte dtalking abou tthe changes you made yestreday 12:57:12 i shared the travis output with him 12:57:56 fabricioo0: it looks like the values of 'added', 'removed', and 'present' are still strings. 12:58:34 fabricioo0: even though they are actually data structures that have a keys and values 12:59:42 I tried to write a new serializer, but as the content could be anything I couldn't make progress 13:01:12 jsherrill: the challenge we are facing here is that the content_summary.added, removed, and present, can have any content type listed 13:01:33 and we need to figure out how to describe that properly with openapi schema 13:02:18 oof 13:02:44 i will reach out to the openapi-generator community and see if they have any recommendations 13:02:49 there's no way to just let it render to json without specifying a structure? 13:03:07 jsherrill: when you say render json ... what do you mean? 13:03:39 well its obviously got a hash and is rendering that as a string 13:03:48 jsherrill: i think we want to keep it as a hash 13:03:50 if it had just been rendered as json, it would be fine 13:04:03 jsherrill: what if it stayed a hash 13:04:05 ? 13:04:14 a hash as json or a hash as ruby? 13:04:23 ruby hash of the json 13:04:39 you mean as a serialized string like that? 13:04:43 noooo 13:04:53 oh, what do you mean? 13:06:09 jsherrill: perhaps i am not understanding ruby correctly. but i was thinking that instead of calling .to_string() on the hash, leave it as is 13:08:20 dkliban: possibly? i guess it depends on how the bindings are behaving if you 'leave it as it is' 13:10:17 jsherrill: right now the value of content_summary.added is a string. and i want that value to be a ruby hash 13:11:05 yeah its worth trying 13:14:27 I will try to make a dynamic serializer to handle the content 13:15:01 fabricioo0: i just sent you an email invite to join a slack channel for openapi-generator 13:15:06 i plan on talking to some folks there 13:53:15 anyone seen this recently ? psycopg2.OperationalError: FATAL: Peer authentication failed for user "pulp" 13:54:06 are you trying to use psql? or when do you get the message? 13:54:28 ipanova, ^ 14:00:15 ipanova: this error happened with https://www.redhat.com/archives/pulp-dev/2019-August/msg00010.html 14:08:35 i just pulled latest changes fro installer, ran vagrant provision and i get this when looking into the logs ttereshc daviddavis 14:12:08 I'm pretty sure it's related to this change but I don't know how to fix it https://github.com/pulp/ansible-pulp/pull/128 14:12:19 I haven't tried to recreate my dev env since it got merged 14:17:28 triage will begin in 13 minutes https://pulp.plan.io/issues?query_id=134 14:30:27 #info asmacdo has joined triage 14:30:27 !start 14:30:27 asmacdo: Error: Can't start another meeting, one is in progress. 14:30:28 asmacdo: asmacdo has joined triage 14:30:45 #info dkliban has joined triage 14:30:45 !here 14:30:45 dkliban: dkliban has joined triage 14:30:55 #info daviddavis has joined triage 14:30:55 !here 14:30:55 daviddavis: daviddavis has joined triage 14:31:02 oh wow, i guess this is the end of the a 5 day long triage... whoops 14:31:09 !next 14:31:10 asmacdo: 2 issues left to triage: 5254, 5247 14:31:10 #topic https://pulp.plan.io/issues/5254 14:31:11 RM 5254 - jsherril@redhat.com - NEW - mirror mode cannot be set on a remote 14:31:12 https://pulp.plan.io/issues/5254 14:31:35 why did we remove it? 14:31:51 oh because remotes are shared across repos 14:31:58 yeah 14:32:05 probably a story 14:32:07 and at sync time we want the user to decide 14:32:39 #info dalley has joined triage 14:32:39 !here 14:32:39 dalley: dalley has joined triage 14:33:04 the problem which I agree with is that users might forget what option they were using 14:33:19 #info ggainey has joined triage 14:33:19 !here 14:33:19 ggainey: ggainey has joined triage 14:33:31 #info ttereshc has joined triage 14:33:31 !here 14:33:31 ttereshc: ttereshc has joined triage 14:33:47 daviddavis: so is the solution to bring back the mirror attribute? 14:33:50 #info ipanova has joined triage 14:33:50 !here 14:33:50 ipanova: ipanova has joined triage 14:34:08 does mirror make sense for 100% of plugins? 14:34:18 the same argument was made for download policy, and thats now on the remote 14:34:39 #info ppicka has joined triage 14:34:39 !here 14:34:39 ppicka: ppicka has joined triage 14:34:42 we have plugins that don't support download policy but that's on remote 14:35:26 jsherrill: each remote implements it 14:35:32 if we do put it on the remotes, they should be on the plugin remotes 14:35:37 yep 14:35:45 ok ... let's convert to story 14:36:08 I don't think it should go on remotes but I'll post on the issue 14:36:20 daviddavis: sounds good 14:36:27 +2 14:36:30 1 14:36:49 #idea Proposed for #5254: daviddavis will convert to story and comment 14:36:49 !propose other daviddavis will convert to story and comment 14:36:49 asmacdo: Proposed for #5254: daviddavis will convert to story and comment 14:37:01 #agreed daviddavis will convert to story and comment 14:37:01 !accept 14:37:01 asmacdo: Current proposal accepted: daviddavis will convert to story and comment 14:37:02 asmacdo: 1 issues left to triage: 5247 14:37:03 #topic https://pulp.plan.io/issues/5247 14:37:03 RM 5247 - lmjachky - NEW - An incorrect example of a distribution creation 14:37:04 https://pulp.plan.io/issues/5247 14:37:22 #idea Proposed for #5247: accept and add to sprint 14:37:22 !propose other accept and add to sprint 14:37:22 asmacdo: Proposed for #5247: accept and add to sprint 14:37:26 +1 14:37:34 +1 14:37:34 +1 14:37:39 +1 14:37:51 #agreed accept and add to sprint 14:37:51 !accept 14:37:51 asmacdo: Current proposal accepted: accept and add to sprint 14:37:52 asmacdo: No issues to triage. 14:38:02 open floor anyone? 14:38:14 ohh I have one 14:38:17 let me find it 14:38:43 https://pulp.plan.io/issues/5035 14:39:47 so you can't do re #5035 if its already at modified? 14:40:44 correct 14:41:03 https://git.io/fj5wk 14:41:33 yeah ... you can't 14:41:33 ohhh. for some reason i was thinking this had to do with the automation 14:41:46 usually we set the issue back to POST but we sometimes forget to move it back to MODIFIED 14:41:49 which is problematic 14:42:11 so do we want to add MODIFIED in there too? 14:42:35 I would say yes since the issue is MODIFIED and hasn't been released 14:43:08 yeah ... i am just worried about people typing wrong number by mistake 14:44:26 i dont think we are doing the states correctly wrt releases 14:44:29