Re: Taskotron Fedmsgs Format
On Thu, Jan 29, 2015 at 08:53:22AM -0700, Tim Flink wrote:
On Wed, 28 Jan 2015 13:42:23 -0500
Ralph Bean rb...@redhat.com wrote:
On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1,
'msg': {'check': {'name': 'upgradepath',
'type': 'bodhi_update',
'item': 'wireshark-1.10.12-1.fc20',
'arch': 'x86_64'},
'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name':
'wireshark'}], 'result': {'id': 123456,
'submit_time': '2015-01-27 14:22:53.584210',
'outcome': 'failed',
'summary': '...',
'job_url':
'http://resultsdb.fedoraproject.org/...', 'log_url':
'http://taskotron.fedoraproject.org/...'} },
'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
'timestamp': 1395760459,
'topic': 'org.fedoraproject.{prod, stg,
dev}.taskotron.result.new', 'username': 'taskotron'
}
The 'packages' field would be used for all the packages that are
relevant to the check which result is being sent in the fedmsg, so
they can be returned by fedmsg.meta.msg2packages and searched on
using datagrepper.
Looks quite good to me. :)
So depcheck results would include a long list of relevant packages?
It could, yes. The native output format of depcheck is per-rpm but
we've always considered updates to be the lowest-level unit against
which depcheck reports because it doesn't make sense to fail only part
of an update. However, I think we can add a list of affected packages
to the fedmsgs emitted for depcheck results.
The thing I'm wondering is if there are interesting use cases which
aren't well covered by this. Package-specific checks wouldn't be a
problem, nor would image-based checks. The only thing I can think of
that may not work so well is stuff like the gnome-installed-tests which
aren't specific to a single package or a single deliverable. Would FMN
allow for folks to subscribe to messages from a specific check or are
only certain fields capable of triggering notification?
Yeah, we could write a specific FMN rule for specific taskotron
checks. They are just little python functions that accept a message
and return true or false.
See https://github.com/fedora-infra/fmn.rules/tree/develop/fmn/rules
pgpDAce3_KXaz.pgp
Description: PGP signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Taskotron Fedmsgs Format
On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
Please find proposed format for taskotron fedmsgs below.
{ 'i': 1,
'msg': {'check': {'name': 'upgradepath',
'type': 'bodhi_update',
'item': 'wireshark-1.10.12-1.fc20',
'arch': 'x86_64'},
'packages': [{'nvr': 'wireshark-1.10.12-1.fc20', 'name':
'wireshark'}],
'result': {'id': 123456,
'submit_time': '2015-01-27 14:22:53.584210',
'outcome': 'failed',
'summary': '...',
'job_url': 'http://resultsdb.fedoraproject.org/...',
'log_url': 'http://taskotron.fedoraproject.org/...'}
},
'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
'timestamp': 1395760459,
'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new',
'username': 'taskotron'
}
The 'packages' field would be used for all the packages that are relevant
to the check which result is being sent in the fedmsg, so they can be
returned by fedmsg.meta.msg2packages and searched on using datagrepper.
Looks quite good to me. :)
So depcheck results would include a long list of relevant packages?
pgpsRtF15T55O.pgp
Description: PGP signature
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Planning: Fedmsg Integration
On Thu, Dec 11, 2014 at 11:10:55PM -0700, Tim Flink wrote: Almost forgot about this, even though I was talking about it earlier today. The current plan for bodhi2, as I understand it, is shooting for production deployment in January or February. This affects us because we will no longer be submitting bodhi comments as a feedback mechanism for completed tasks. Before this happens, we will need to enhance resultsdb-backend to send out fedmsgs that can be processed by fedmsg-notifier (fmn [1]) [1] https://apps.fedoraproject.org/notifications/ Outside of the technical requirements here, we need to figure out whether or not receiving notifications will be optional for maintainers or not. This will require some conversation with FESCo as it's more of a policy thing but will need driving from our end. IMHO, it should be optional, but opt-out. (So we would need to include it in the new defaults that go out with the next release of fmn). The more technical bits that I'm aware of at this point are: - Decide on a schema for the messages we emit * org.fedoraproject.taskotron.result.package.foo-1.2-3.fc99 etc. (not even sure that's a valid message) I'd rather not have a variable in the package topic -- that will give us an enormous number of total unique topic in the datagrepper database. How about something like: * org.fedoraproject.taskotron.result.new ..and embed the update, build, and/or package name in the body of the message. - Figure out what information should be in the emitted messages - Figure out where the messages should be emitted from and add/modify code to get that happening (resultsdb-backend makes the most sense to me right now but am open to other ideas) - Get certs for the emitting machines - Start emitting messages in staging As a reward when it's done: - rip out the bodhi comment code from litaskotron and burn it over a bonfire while we toast marshmallows for s'mores I'd like to have this ready for deployment in staging by early January, so that it can run for a while before we move it into production but I'm not sure if that's compatible with vacation schedules. For what its worth, bodhi2 (unreleased) currently just queries the resultsdb JSON API to figure out how it should mark or block updates... all without fedmsg. fedmsg just gives us a nice notification layer for end users. There is another layer of integration that we've not yet begun to stub out in bodhi2, which is to publish a message when its backend begins a mash. We have been hoping that taskotron could listen for that new message and begin a depcheck run against all the packages in the koji tag that bodhi is about to mash -- and then later, publish a message when that check is done. Bodhi would block, waiting for that response, and then only proceed with the mash if that depcheck run passes. pgpPH_OZT4ZgK.pgp Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Project Locations and Basic Setup
On Mon, Apr 07, 2014 at 03:19:41AM -0400, Martin Krizek wrote: - Original Message - From: Tim Flink tfl...@redhat.com To: qa-devel@lists.fedoraproject.org Sent: Friday, April 4, 2014 4:50:25 PM Subject: Project Locations and Basic Setup I think most of this came up in an earlier thread but I'm not finding it right now, so I'm starting a new one. I'm proposing that we make all the taskotron-related projects as similar as we can with regard to git repo setup, location and how we do reviews. If we keep them all slightly different, it makes asking for contributions more difficult and the contributions guide (which still needs to be written :-/) more complicated. To be specific, the repos that I'm including in this are: - libtaskotron - taskotron-trigger - resultsdb - resultsdb_frontend - resultsdb_api - pytap13 - fake_fedorainfra The settings that I'm proposing for all those repos are: - use gitflow and set 'develop' as the default branch - host projects under bitbucket/fedoraqa * makes it easier to say find our projects at this url instead of find projects X,Y and Z here. find A and B here - code submissions and issues/tasks are tracked through phabricator Any objections to doing this to all the repos I mentioned? No objections. In addition, we need to make sure that each repo has its .arcconfig file with correct project_id. No objections. pgpwP4JzpzA7c.pgp Description: PGP signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
