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