14:30:16 <fao89> #startmeeting Pulp Triage 2020-08-25
14:30:16 <fao89> #info fao89 has joined triage
14:30:16 <fao89> !start
14:30:16 <pulpbot> Meeting started Tue Aug 25 14:30:16 2020 UTC.  The chair is fao89. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:16 <pulpbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:30:16 <pulpbot> The meeting name has been set to 'pulp_triage_2020-08-25'
14:30:16 <pulpbot> fao89: fao89 has joined triage
14:31:47 <x9c4> #info x9c4 has joined triage
14:31:47 <x9c4> !here
14:31:47 <pulpbot> x9c4: x9c4 has joined triage
14:31:53 <daviddavis> #info daviddavis has joined triage
14:31:53 <daviddavis> !here
14:31:53 <pulpbot> daviddavis: daviddavis has joined triage
14:32:10 <ipanova> #info ipanova has joined triage
14:32:10 <ipanova> !here
14:32:10 <pulpbot> ipanova: ipanova has joined triage
14:32:18 <fao89> !next
14:32:19 <fao89> #topic https://pulp.plan.io/issues/7389
14:32:19 <pulpbot> fao89: 5 issues left to triage: 7389, 7387, 7386, 7356, 7321
14:32:20 <pulpbot> RM 7389 - osapryki - NEW - Cancelled tasks are processed by worker
14:32:21 <pulpbot> https://pulp.plan.io/issues/7389
14:32:58 <ggainey> #info ggainey has joined triage
14:32:58 <ggainey> !here
14:32:58 <pulpbot> ggainey: ggainey has joined triage
14:33:11 <daviddavis> accept and add to sprint
14:33:23 <fao89> #idea Proposed for #7389: accept and add to sprint
14:33:23 <fao89> !propose other accept and add to sprint
14:33:24 <pulpbot> fao89: Proposed for #7389: accept and add to sprint
14:33:27 <ipanova> +1
14:33:31 <fao89> #agreed accept and add to sprint
14:33:31 <fao89> !accept
14:33:31 <pulpbot> fao89: Current proposal accepted: accept and add to sprint
14:33:31 <fao89> #topic https://pulp.plan.io/issues/7387
14:33:32 <pulpbot> fao89: 4 issues left to triage: 7387, 7386, 7356, 7321
14:33:33 <pulpbot> RM 7387 - osapryki - NEW - Tasks not delivered to resource-manager are not cleaned up
14:33:34 <pulpbot> https://pulp.plan.io/issues/7387
14:34:03 <ipanova> i think we have this on the sprint
14:34:30 <ppicka> #info ppicka has joined triage
14:34:30 <ppicka> !here
14:34:30 <pulpbot> ppicka: ppicka has joined triage
14:34:45 <ttereshc> #info ttereshc has joined triage
14:34:45 <ttereshc> !here
14:34:45 <pulpbot> ttereshc: ttereshc has joined triage
14:34:47 <dalley> yeah this is one of about 3 duplicates for this issue...
14:34:49 <ipanova> ah no https://pulp.plan.io/issues/6533 this one is stuck in running
14:35:10 <ipanova> lets at least relate them in case root cause is different
14:35:19 <daviddavis> +1
14:35:35 <dalley> this is the other one https://pulp.plan.io/issues/6449
14:35:59 <fao89> #idea Proposed for #7387: accept and add to sprint and relate to similar issues
14:35:59 <fao89> !propose other accept and add to sprint and relate to similar issues
14:35:59 <pulpbot> fao89: Proposed for #7387: accept and add to sprint and relate to similar issues
14:36:36 <dalley> given the reports from multiple different users I'm going to take the hint that I need to start working on that issue again
14:36:36 <ttereshc> +1 to relate
14:36:45 <daviddavis> 7387 is a dupe of 6449
14:36:49 <ipanova> i would not add to the sprint because we have already one "similar" on the sprint
14:37:01 <daviddavis> or at least the steps to reproduce are the same as here https://pulp.plan.io/issues/6449#note-1
14:37:06 <fao89> close?
14:37:16 <ggainey> +1 to relate - altho 7387 looks like a dup of 6449, yeah I'd close-as-dup
14:37:17 <ppicka> relate?
14:37:25 <daviddavis> yea, and I want to bump the priority of 6449
14:37:28 <daviddavis> to high
14:37:41 <daviddavis> I can handle this
14:37:46 <ggainey> kk
14:37:51 <daviddavis> I'm talking with alex later today
14:38:05 <ipanova> ok
14:38:18 <daviddavis> anyone against bumping the priority?
14:38:25 <fao89> #idea Proposed for #7387: close as duplicate and relate to similar issues
14:38:25 <fao89> !propose other close as duplicate and relate to similar issues
14:38:25 <pulpbot> fao89: Proposed for #7387: close as duplicate and relate to similar issues
14:38:31 <fao89> #agreed close as duplicate and relate to similar issues
14:38:31 <fao89> !accept
14:38:31 <pulpbot> fao89: Current proposal accepted: close as duplicate and relate to similar issues
14:38:32 <fao89> #topic https://pulp.plan.io/issues/7386
14:38:32 <pulpbot> fao89: 3 issues left to triage: 7386, 7356, 7321
14:38:33 <pulpbot> RM 7386 - osapryki - NEW - Task that does not exist in worker or resource-manager are never cleaned up
14:38:34 <pulpbot> https://pulp.plan.io/issues/7386
14:39:58 <daviddavis> does the installer expect pulp to be stopped when upgrading?
14:40:30 <daviddavis> I'm wondering what the severity is and whether users other than ansible will hit this
14:41:04 <ttereshc> good question, I think at the moment it's expected to stop pulp services
14:41:20 <fao89> I think the installer does not expect it, but I'm not sure about the operator
14:42:25 <daviddavis> I'm tempted to either skip or just accept for now
14:43:08 <ipanova> +1 to just accept
14:43:13 <fao89> I think it is better to skip, so we discuss it on Friday
14:43:14 <ggainey> it feels like a low-incidence issue at best - you have to be multi-node, you have to be installing a new version that has renamed a task, and you have to invoke a task by its "old" name at exactly the right (wrong?) time
14:43:27 <daviddavis> ggainey: agreed
14:43:55 <fao89> #idea Proposed for #7386: Leave the issue as-is, accepting its current state.
14:43:55 <fao89> !propose accept
14:43:55 <pulpbot> fao89: Proposed for #7386: Leave the issue as-is, accepting its current state.
14:44:08 <ggainey> yeah, works4me
14:44:11 <daviddavis> +1
14:44:18 <fao89> #agreed Leave the issue as-is, accepting its current state.
14:44:18 <fao89> !accept
14:44:18 <pulpbot> fao89: Current proposal accepted: Leave the issue as-is, accepting its current state.
14:44:19 <pulpbot> fao89: 2 issues left to triage: 7356, 7321
14:44:19 <fao89> #topic https://pulp.plan.io/issues/7356
14:44:20 <pulpbot> RM 7356 - ipanova@redhat.com - NEW - As a user I can name a repo version and rollback to a named repo version
14:44:21 <pulpbot> https://pulp.plan.io/issues/7356
14:44:41 <ggainey> story?
14:44:49 <ttereshc> why was it moved to the issue tracker?
14:44:53 <ipanova> this was brought up as an idea from clouddist feedback meeting
14:45:06 <ipanova> mostly a prompt for discussion
14:45:12 <ggainey> ah kk
14:45:14 <ttereshc> good topic for the open floor probabl
14:45:16 <ipanova> ttereshc: so it is visible during triage
14:45:20 <fao89> #idea Proposed for #7356: convert to story
14:45:20 <fao89> !propose other convert to story
14:45:20 <pulpbot> fao89: Proposed for #7356: convert to story
14:45:26 <ttereshc> triage is for bugs, imo
14:45:32 <ttereshc> open floor is for the rest
14:45:41 <ipanova> sure, i forgot about openfllor.
14:46:10 <fao89> #agreed convert to story
14:46:10 <fao89> !accept
14:46:10 <pulpbot> fao89: Current proposal accepted: convert to story
14:46:11 <fao89> #topic https://pulp.plan.io/issues/7321
14:46:11 <pulpbot> fao89: 1 issues left to triage: 7321
14:46:12 <pulpbot> RM 7321 - Aant - NEW - pulp_rpm: Cannot synchronize repos behind proxy [Network is unreachable]
14:46:13 <pulpbot> https://pulp.plan.io/issues/7321
14:46:54 <ttereshc> we agreed to add it to the sprint last time
14:47:05 <ppicka> already in sprint
14:47:09 <ipanova> we forgot to mark it  as triaged.
14:47:10 <ppicka> but doesn't have triaged tag
14:47:13 <ttereshc> ah :)
14:47:18 <ggainey> ah kk
14:47:25 <ppicka> I can update
14:47:32 <ttereshc> thx
14:48:10 <ppicka> so 'skip'?
14:48:15 <fao89> !skip
14:48:16 <pulpbot> fao89: No issues to triage.
14:48:23 <fao89> Open floor!
14:48:27 <ttereshc> no, just triage
14:48:33 <ttereshc> nothing to skip
14:48:38 <fao89> https://hackmd.io/@pulp/triage/edit
14:48:52 <ppicka> I meant the command for the bot
14:49:27 <fao89> https://github.com/pulp/pulp-oci-images/pull/13  - How to manage/update our versions?
14:51:15 <fao89> I think we should have a CI/CD meeting to discuss it
14:52:19 <ggainey> hrm, yeah - to pieter's point, I could see things going worng when we're after a pulpcore release, but before plugins are released, yeah?
14:52:34 <x9c4> I think updating the versions of python packages that go into the container has some overlap with the pulp_packaging aproach.
14:52:56 <daviddavis> x9c4: not sure I follow
14:53:31 <daviddavis> ggainey: I am not a pip expert but I think pip would refuse to install incompatible versions of pulpcore + plugins
14:53:36 <x9c4> https://hackmd.io/z8HZw9oyQ7-MAV6W5lse4g This was the idea with the unified release pipeline.
14:54:02 <daviddavis> so have the unified release pipeline bump the versions in the single container?
14:54:22 <daviddavis> I would say in the short term we have two options
14:54:29 <ggainey> daviddavis: that would be good - but it would still cause automation failures, yeah?
14:54:31 <x9c4> Actually have this pipeline build the container image i think.
14:54:50 <x9c4> And yes that is no short term solution.
14:55:08 <daviddavis> 1. we unpin and use latest for now
14:55:14 <daviddavis> 2. we update the release guide to bump the versions
14:55:23 <x9c4> ggainey, the release pipeline would have branches for releases and add plugins there as they are ready.
14:55:34 <ggainey> x9c4: ah, gotcha, thanks
14:56:20 <daviddavis> 1 seems easy and given our recent difficulties with the complexity of releasing, I am kinda leaning towards it until we have the release pipeline up and running.
14:56:52 <ggainey> yeah, adding another manual step to the release-process feels like a suboptimal choice
14:57:16 <ggainey> (and having badly out-of-date images even moreso)
14:57:23 <daviddavis> yea
14:57:32 <ttereshc> +1 to unpin. pip install will fail for a few days after a pulpocre release and then everything is back to normal I guess
14:58:14 <daviddavis> does pip not do dependency solving?
14:58:39 <x9c4> If we can combine that with plugins to be compatible with pulpcore stable +1 images should always build.
14:58:46 <ttereshc> I think it does while installing, not upfront
14:59:30 <daviddavis> ok cool, so I'll update this PR and bring it up for review
14:59:37 <ggainey> can we add some commentary around the implications we're talking about here to the PR?
14:59:41 <ggainey> heh, nm, gmta
15:00:20 <daviddavis> ggainey: I will look into this
15:00:52 <ggainey> +1, thanks
15:00:54 <ggainey> daviddavis++
15:00:54 <pulpbot> ggainey: daviddavis's karma is now 357
15:01:21 <fao89> next topic: https://pulp.plan.io/issues/7356
15:01:30 <fao89> !issue 7356
15:01:31 <fao89> #topic https://pulp.plan.io/issues/7356
15:01:31 <pulpbot> RM 7356 - ipanova@redhat.com - NEW - As a user I can name a repo version and rollback to a named repo version
15:01:32 <pulpbot> https://pulp.plan.io/issues/7356
15:01:47 <ggainey> right
15:02:03 <ggainey> so, mutability and uniqueness were my first two thoughts on reading this
15:02:12 <ggainey> (I like the idea, just need to mull over implications?)
15:03:37 <ipanova> sure, i think keeping the repo version will be desirable
15:03:42 <ipanova> immutable
15:03:48 <ggainey> concur
15:03:53 <x9c4> If the name is provided at creation time there is no problem with immutability.
15:04:08 <daviddavis> the only problem is that users probably want to rename stuff
15:04:11 <ipanova> this feature will also enable rollback for container push repos
15:04:13 <ggainey> sure - I'm trying to think of the user-workflow tho
15:04:35 <daviddavis> they want to label something as 'stable'
15:04:38 <ggainey> yeah - in fact, take the 'stable' label - I mark /5 as stable, I make and test fouor more versions, I now want /9 to be 'stable'
15:04:46 <daviddavis> yea
15:04:53 <ipanova> daviddavis: good point, especially if they will want to re-use some names within a repo
15:04:59 <ggainey> which means I want to change 5, and I don't want to label /9 until *after* I've created and tested it
15:05:03 <ggainey> so 'immutable' is...hard
15:05:12 <ggainey> yah
15:05:22 <daviddavis> if we had labels/tags, repo versions could remain immutable
15:05:28 <ttereshc> I struggle to understand why the label ticket is not covering it if the goal is to identify which one is labeled as stable?
15:05:32 <ggainey> daviddavis: that's where I'm heading in my head
15:05:49 <ggainey> it's not an attribute of a RepoVersion, there exists a tag-to-version model
15:06:00 <daviddavis> the label ticket is strange (https://pulp.plan.io/issues/7127) in that it uses a key-value store
15:06:02 <ggainey> does this make sense outside of my head?
15:06:09 <daviddavis> ggainey: yes
15:06:22 <ipanova> daviddavis: yeah that's why i opened a separate ticket
15:06:35 <daviddavis> yea
15:06:40 <ggainey> so if you want to look up a repo by-label it requires an extra join
15:06:54 <ggainey> (which is fine, I'm talking out loud to see if this makes sense)
15:06:58 <ttereshc> key-value makes it more generic I think. Maybe you'd like to attach multiple label to a repo version, and one would be name=stable
15:07:09 <ggainey> ahhh, interesting
15:07:17 <daviddavis> or use booleans: stable=1
15:07:30 <ggainey> being able to take advantage of the more-general functionality, which we already want, would be good
15:07:40 <ipanova> the idea of tagging a RV by giving a meaningful name i think will improve the user experience we just need to come up with a solution
15:07:45 <ttereshc> yeah, this looks good as well daviddavis
15:08:06 <ggainey> ok, what I'm hearing is we all think this is a good idea, that has several poss solutions
15:08:16 <ipanova> daviddavis: can work but feels strange
15:08:55 <daviddavis> yea, I concur. strange but also more powerful. also we can't do uniqueness with tags/label but I don't know if that's a requirement.
15:08:57 <ggainey> daviddavis: booleans implies that a tag has connotations
15:09:50 <x9c4> key value storage sounds like annotations, while label should be a way to uniquely identify objects.
15:10:03 <ggainey> and for the purposes of this story, a given name can only apply to a single version
15:10:07 <ggainey> yeah
15:10:21 <ttereshc> within a plugin?
15:10:31 <ggainey> ttereshc: within a repo, I would think
15:10:39 <ttereshc> ah yeah, right
15:10:41 <ggainey> all of my RPM repos ave a stable version, for ex
15:10:46 <ipanova> so what i am hearing we want to have key-value store and a pure string
15:10:57 <ggainey> ipanova: so far, yeah
15:11:13 <x9c4> yeah, it sounds like two different features to me.
15:11:20 <ggainey> I tink we need some user-stories/usecases to flush out the implications for this story
15:11:29 <ttereshc> still sounds the same to me :D
15:12:01 <ipanova> ok, i think i am dumping the idea of adding 'name' to the RV because we want to kepp RV immutable but still change/re-use the name which basically conflicts
15:12:09 <ggainey> yeah
15:12:33 <daviddavis> ipanova: did they specifically ask for uniqueness constraints?
15:12:34 <ggainey> for immutability, this would def need to be something that "points to" a version, rather than is-a
15:12:42 <x9c4> +1
15:12:45 <ttereshc> x9c4, I think a label can't uniquely identify an object, it will still be only a part of unique constraint
15:12:58 <ggainey> daviddavis: if the name isn't unique, then how do you know which 'foo' you're rolling back to?
15:13:26 <x9c4> It is still one to many, but the name can only refer to one object at a time.
15:13:41 <daviddavis> I'm asking because I don't think of annotations as offering unique constraints
15:14:04 <ipanova> daviddavis: i gues it would make sense to have a unique name within the repo
15:14:10 <ggainey> daviddavis: yeah - see prev RE 'need to flesh out userstories' before we go too far down the design path
15:14:15 <ttereshc> yeah, I see where you are going daviddavis
15:14:28 <x9c4> If you can tag several versions as being stable=True that is a different thing.
15:14:35 <daviddavis> ggainey: yea, that's why I was asking what the user was asking for
15:14:56 <ggainey> x9c4: I'm focused on "would be easy to identify to which version to rollback"
15:15:04 <ggainey> we're looking for 'a' version
15:15:06 <ggainey> by name
15:15:11 <ipanova> yep
15:15:51 <daviddavis> yea, so we need more user stories because I am also getting the feeling that we are trying to solve disparate problems
15:15:52 <ggainey> ipanova: if feels like what we're looking for with this specific story, is a way to create an alias for a specific repo/version
15:16:14 <ggainey> daviddavis: definitely, there are like three-ish interesting-things-to-solve in this area :)
15:16:45 <daviddavis> yea
15:16:51 <ipanova> sure, we can write down some usecases
15:17:10 <daviddavis> is tagging/labels/annotations/wtfever on the agenda for pulpcon?
15:17:11 <ttereshc> ggainey, and an important requirement(?) is an ability to update this alias
15:17:22 <ggainey> ttereshc: zacly
15:17:23 <ipanova> daviddavis: no
15:17:48 <ipanova> we could add to brainstorm
15:18:38 <ipanova> ok, i will try to summarize our discussion and if we decide we could have a follow up discussion on pulpcon
15:18:47 <ggainey> ok, sounds good
15:18:48 <ttereshc> +1 to add to pulpcon if use cases are known
15:18:52 <daviddavis> +1
15:19:01 <ggainey> there's a slot available on Thurs
15:19:05 <ggainey> +1
15:19:06 <ipanova> i think labels would need to be implemented soon because of galaxy
15:19:26 <x9c4> +1
15:20:23 <fao89> #endmeeting
15:20:23 <fao89> !end