Re: [kernelci-members] Working with the KernelCI project

Dmitry Vyukov
2020-10-02T07:52:13Z

On Thu, Oct 1, 2020 at 7:02 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Thu, Oct 1, 2020 at 6:34 PM Nikolai Kondrashov
> <Nikolai.Kondrashov@redhat.com> wrote:
> >
> > On 10/1/20 7:00 PM, Dmitry Vyukov wrote:
> > > On Thu, Oct 1, 2020 at 5:52 PM Nikolai Kondrashov
> > > <Nikolai.Kondrashov@redhat.com> wrote:
> > >>
> > >> On 10/1/20 6:49 PM, Nikolai Kondrashov wrote:
> > >>> On 10/1/20 5:48 PM, Dmitry Vyukov via groups.io wrote:
> > >>> > On Thu, Oct 1, 2020 at 3:32 PM Nikolai Kondrashov
> > >>> > <Nikolai.Kondrashov@redhat.com> wrote:
> > >>> >>
> > >>> >> On 10/1/20 1:48 PM, Nikolai Kondrashov wrote:
> > >>> >> > Here are the things which could be improved:
> > >>> >>
> > >>> >> Oh, and another thing: could you avoid re-sending the identical
> > >>> >> revisions/builds you've already sent? I.e. send them only once, unless you
> > >>> >> have fields to add? Each of those costs us a row in the database, which is not
> > >>> >> a big deal, but would be good to avoid.
> > >>> >
> > >>> > Do you see that we send dups? I've added logic to not send dups and
> > >>> > from what I see it's working.
> > >>>
> > >>> Please find attached a zip archive with seven submissions from about six hours
> > >>> ago. Each has revisions with the same id and git_commit_hash. Some of those
> > >>> revisions have different discovery_time, and that alone shouldn't really be
> > >>> the reason to resend. Each of those submissions have a build object, but some
> > >>> of them are repeated.
> > >>>
> > >>> Revision with that git_commit_hash was submitted at least 72 times.
> > >>
> > >> And now the file is attached :D
> > >
> > > This is intentional (in the current implementation) and is a
> > > consequence of the fact that we always send all 3 entities for each
> > > issue/test failure. It's much simpler on our side this way. If we
> > > would send a test failure multiple times it would be unintentional.
> >
> > I see.
> >
> > > Identical builds should have the same id, though. And if they have
> > > different id's, then these are different builds.
> >
> > Sure.
> >
> > > Revisions were discovered separately by different instances, that's
> > > why they have different discovery time. Consider that as if different
> > > origin systems would discover it separately. Since discovery time is
> > > not an inherent property of the commit itself, there is no way they
> > > can agree on it.
> >
> > Ah, I see now why. Yeah, it's similar to multiple systems submitting the same
> > revision. Although we don't have systems submitting the same build multiple
> > times.
> >
> > > Will it be better if we don't send discovery time at all?
> >
> > No, it's OK to submit the discover time multiple times, but we can't say which
> > one will be displayed :)
> >
> > > Amount of duplication for builds/revisions is capped by the number of
> > > bugs we discover, since build/revision is only sent with a bug once.
> > > So it's not that it's unlimited.
> >
> > I think it's OK that you have some duplication, and certainly OK for the
> > start. Let's get on with sending the data and see how much actual duplication
> > we get, how it affects performance, and how the de-duplication implementation
> > goes :)
>
> The new format is now published by syzbot itself:
> https://staging.kernelci.org:3000/d/test/test?orgId=1&var-dataset=playground_kernelci04&var-id=syzbot:60b38542a0dfb2e0f746
>
> So, do we switch to prod instance? Do you receive notifications now?
> Do we need to fix anything else before the switch?
>
> I don't see anything from syzbot at:
> https://groups.io/g/kernelci-results-staging/topics
> How can I see/subscribe to these notifications?
>
> Since syzbot database now memorizes what was published to kcidb to
> avoid dups, the switch will require some manual database surgery to
> make it re-publish bugs. So I want to make sure we did not miss
> something simple that we could do before the switch.
>
> The switch involves just changing the topic to "kernelci_new", right?

I am preparing for the switch and will do it unless I hear from you soon.
Since you already gave green light above, I assume we are good now.