Re: RFR: New Dist-Git Task Storage Proposal
Why do you prefer to have the "taskotron" directory instead of "taskotron" namespace (the same as for docker files)? TBH, this will make synchronization between RHEL and Fedora much harder, because I can't see any internal use for "taskotron" directory. Vít Dne 12.9.2016 v 22:44 Tim Flink napsal(a): > I wrote up a quick draft of the new dist-git task storage proposal that > was discussed in Brno after Flock. > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/ > > Please review the document and either let me know (or fix in the wiki > page) things which aren't clear or bits that I forgot. > > Tim > > > ___ > qa-devel mailing list > qa-devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org signature.asc Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: Resultsdb v2.0 - API docs
On Tue, Sep 13, 2016 at 8:19 PM, Randy Barlow wrote: > Will the api/v1.0/ endpoint continue to function as-is for a while, to > give integrators time to adjust to the new API? That would be ideal for > Bodhi, so we can adjust our code to work with v2.0 after it is already in > production. If not, we will need to coordinate bodhi and resultsdb releases > at the same time. > Hey! There is a plan for the v1.0 endpoint to work, even though being a bit limited in features, but from what I remember about Bodhi, that will not affect it at all. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: Resultsdb v2.0 - API docs
On Mon, Sep 12, 2016 at 11:39 PM, Tim Flink wrote: > > I think we talked about this in person earlier but I didn't write any > notes about it and I don't recall the details. > > How exactly are we going to be using Groups? The first thing that comes > to mind is to group results by execution so that there would be a group > of results which were all produced from the same run of the same task. > That's kinda what we're using Job for in resultsdb 1.0 right now, > anyways. > > I realize that the docs for resultsdb are supposed to be > not-specific-to-taskotron but was there anything else we thought the > Group might be useful for? > > Also, what do we want to do about a link to execdb? If we're planning > to have a group for each execution's results, that could be the group's > ref_url but that relies on convention which could change if Group is > used for more than just grouping results by execution. > I see two (maybe three) options - either we'll be using the groups in the same way we used Jobs - to group results per execution as we do now, and use the group's ref_url to point to execdb. If we ever need to use the groups for more than that, then we could just have the result in more than one group, and set meaningful descriptions. The other way would be to not use Groups at all, and just store the execdb's UUID in the key-value store. Those would then be rendered to an URL in the frontend. Last option would be a combination of both - we'd be using Groups as we do now to group by execution, but instead of the "default" resultsdb_frontend, we'd use something tailored for taskotron - we could show links to execdb in the results "view", and either disregard the existence of groups alltogether, or just have a special description (like "ExecDB related Group - ") that would get filtered out in the default "group" view. I don't really see one being directly better than the others it's just what we want to do. I did not put much thought to it, as I just expected us to keep it basically the same. Do you have any ideas? > I assume that the new API will also help fix some of the slowness we've > been seeing? IIRC, there were some schema changes which would probably > help with query time. > > Tim Yep, most of what was really slow should be solved now - or at least it seemed so from my tests. The only thing we still have troubles are the really sparse results - the issue which we thought could get solved by the new Postgres, but wasn't. On the other hand, it is a non-issue, as long as the query is limited by datetime range. If you only care about results that are "newer than X" the amount of data really gets cut down, and the queries are fast, even for the sparse results, since the DB does not need to crawl the whole dataset to be sure there's only LIMIT-n results. This is how Bodhi queries the ResultsDB now - they use 'submitted' timestamp as a constraint. If we communicate this behaviour, I think we'll be fine. I would almost go as far as setting a default time-constraint to (and I'm just thinking out loud here, no reasons for the number whatsoever) three months, and be done with it - if you ever want older results, just set the time-constraint yourself, and be avare that it probably will take time. I don't see a reason we (as in FedoraQA and the related processes) would need to regularly access results older than that anyway. J. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: RFR: New Dist-Git Task Storage Proposal
On Tue, Sep 13, 2016 at 4:20 PM, Tim Flink wrote: > On Mon, 12 Sep 2016 14:44:27 -0600 > Tim Flink wrote: > > > I wrote up a quick draft of the new dist-git task storage proposal > > that was discussed in Brno after Flock. > > > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/ > new_distgit_task_storage_proposal/ > > > > Please review the document and either let me know (or fix in the wiki > > page) things which aren't clear or bits that I forgot. > > I added more information to the wiki page about the default, or bare > executable case which we discussed during/after flock. > > Tim > LGTM - I'd just add a link to documentation for the results.yaml format, if we have any (if we don't then we'd better write one :D) ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting
> # QA Tools Video "Standup" Meeting > # Date: 2016-09-14 > # Time: 14:00 UTC > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > # Location: https://bluejeans.com/2509415264 > > One discussion that came up after Flock was that doing a video meeting > would be worth trying to see how it works for us in terms of > collaborating. > > In that vein, we're going to try this and see how well it works. This > will be in bluejeans which does require flash and/or plugins to work. > I'm not overly tied to it, this is just the easiest option for now :) > > https://bluejeans.com/2509415264 > > The agenda is pretty simple: everyone takes a turn saying what they're > working on this week and what, if anything, is keeping them from making > progress. > > Hope to see people there. > > Tim Hi Tim, please add this to fedocal next time, I noticed the email only today (and only because others told me). Thanks. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: RFR: New Dist-Git Task Storage Proposal
On Wed, 14 Sep 2016 10:28:17 +0200 Vít Ondruch wrote: > Why do you prefer to have the "taskotron" directory instead of > "taskotron" namespace (the same as for docker files)? TBH, this will > make synchronization between RHEL and Fedora much harder, because I > can't see any internal use for "taskotron" directory. One of the things that we're prioritizing is ease of use for packagers. The feedback we've received thus far is that keeping everything in the same git repo is the preferred way to store checks. I'm of the belief that if this isn't as easy to use as falling off a horse, we're not going to see as much adoption as we could. Moving all the checks into a separate git repository is another barrier to entry. Is adding a directory to dist-git that big of a deal? I'm not sure I understand how a few more directories will make synchronization that much more difficult - RHEL can just ignore the "taskotron" directory if they're not using it, no? Tim > Dne 12.9.2016 v 22:44 Tim Flink napsal(a): > > I wrote up a quick draft of the new dist-git task storage proposal > > that was discussed in Brno after Flock. > > > > https://phab.qadevel.cloud.fedoraproject.org/w/taskotron/new_distgit_task_storage_proposal/ > > > > Please review the document and either let me know (or fix in the > > wiki page) things which aren't clear or bits that I forgot. > > > > Tim > > > > > > ___ > > qa-devel mailing list > > qa-devel@lists.fedoraproject.org > > https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org > > > pgpsmMHdEUkAG.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting
On Wed, 14 Sep 2016 06:38:09 -0400 (EDT) Kamil Paral wrote: > > # QA Tools Video "Standup" Meeting > > # Date: 2016-09-14 > > # Time: 14:00 UTC > > (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) > > # Location: https://bluejeans.com/2509415264 > > > > One discussion that came up after Flock was that doing a video > > meeting would be worth trying to see how it works for us in terms of > > collaborating. > > > > In that vein, we're going to try this and see how well it works. > > This will be in bluejeans which does require flash and/or plugins > > to work. I'm not overly tied to it, this is just the easiest option > > for now :) > > > > https://bluejeans.com/2509415264 > > > > The agenda is pretty simple: everyone takes a turn saying what > > they're working on this week and what, if anything, is keeping them > > from making progress. > > > > Hope to see people there. > > > > Tim > > Hi Tim, > > please add this to fedocal next time, I noticed the email only today > (and only because others told me). Sure. The funny thing is that I'm the other way around - if something gets added to fedocal, I'm not likely to notice but I will notice something sent out to the lists I watch closely :) Tim pgpK9gOKOZx5Z.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting
> > Hi Tim, > > > > please add this to fedocal next time, I noticed the email only today > > (and only because others told me). > > Sure. The funny thing is that I'm the other way around - if something > gets added to fedocal, I'm not likely to notice but I will notice > something sent out to the lists I watch closely :) Yeah, I usually do that as well, unless I'm swamped with wayland bugs! But I'm subscribed to Fedora QA calendar on my phone, so I notice a new meeting right away. Not sure about others and their approaches. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
Re: 2016-09-14 @ 14:00 UTC - QA Tools Video "Standup" Meeting
On Mon, 12 Sep 2016 09:53:53 -0600 Tim Flink wrote: > One discussion that came up after Flock was that doing a video meeting > would be worth trying to see how it works for us in terms of > collaborating. > > In that vein, we're going to try this and see how well it works. This > will be in bluejeans which does require flash and/or plugins to work. > I'm not overly tied to it, this is just the easiest option for now :) That seemed to go relatively well but I need to remember to push the record button next time so that folks unable to attend can see what was discussed. One of the topics that came up was how often to do these video meetings. Having additional weekly meetings via video seems like overkill but if there's an appropriate in-depth topic, meeting via video to talk instead of type would be useful. The two options we came up with are: 1. Switch the first qadevel meeting of every month to be via video, making sure that an agenda is sent out early enough for folks to be prepared. 2. Pencil in a video meeting once or twice a month on the Wednesday after qadevel meetings. Ask for video topics during the qadevel meeting and on email. If there are enough topics suggested which would benefit from talking instead of typing, meet on the following Wednesday to discuss via video. If there is no need to meet via video, skip it. I realize that I'm changing things up a little bit from what we were talking about at the end of the meeting but I have a small concern about option 1 - one of the issues that we had today is that folks weren't prepared because we didn't set an agenda. If we switch one qadevel meeting per month to video, how do we want to handle setting the agenda early enough so that participants have enough time to prepare? Any thoughts or preferences? Tim pgpgYPWZ3f1_I.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
