I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
Hi!
I usually tend to create a separate WS for such things (and separate repo). This way you can easily move it wherever you want (changing CNAME records only). Fully featuring the ideas of SOA. Anyway. Only my way to do it...
-of (mobile)
Am 17.06.2013 um 19:45 schrieb "Ralph Bean" <rbean@redhat.commailto:rbean@redhat.com>:
I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.comhttp://gh.com. Any thoughts? _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.orgmailto:infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
<inline.txt>
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
I agree with the implied nervousness towards this degree of integration.
Repository-wise, I think we need a public repository so, although lockbox can have public repos, something already doing public repos is probably better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements. That's hosted at fedorahosted and changes are discussed o nthe mailing lists. So it's possible to shoehorn that into our existing infrastructure. I bet that both comps.xml and badges would be more efficient on github, though.
Unlike code where it's only the developers of the code that will be impacted if github changes their policies or stability degrades, this would be something that is used by people who are more end-users of the badge application which is a slightly wider audience. We've changed that sort of thing before, though -- translations for Fedora went from elvis.rh.com to transifex.fp.o to transifex.net. So we could switch people to a different platform if we had to in the future....
The repo would also be consumed by our services -- the badges application would need to have some sort of access to the data stored there. I think, for that, it might be better to use our own infrastructure as that leaves us in control of the stability, etc.
Perhaps, as a minimum, we need to get the github-fedorahosted mirroring setup if we want to host the workflow on github? That way we'd have a repo in our control that we can have our services work against. And we'd be ready to switch the canonical source of hte data if we needed to. (I'm open to also saying no to github for this use but I don't want to stand in the way either).
-Toshio
On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
I agree with the implied nervousness towards this degree of integration.
Repository-wise, I think we need a public repository so, although lockbox can have public repos, something already doing public repos is probably better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements. That's hosted at fedorahosted and changes are discussed o nthe mailing lists. So it's possible to shoehorn that into our existing infrastructure. I bet that both comps.xml and badges would be more efficient on github, though.
The problem with both gh and hosted for comps or for this is that it means those resources need to 'freeze' when we freeze. That's rotten, imo, for comps alone - but if we needed to freeze and were counting on gh being up right before a release? It would be painful to have that dep hung up that way.
I think we cannot rely on external services and I'm not even enamored of relying on fedorahosted b/c, ostensibly, it doesn't freeze.
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/17/2013 02:50 PM, seth vidal wrote:
On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too
many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
I agree with the implied nervousness towards this degree of integration.
Repository-wise, I think we need a public repository so, although lockbox can have public repos, something already doing public repos is probably better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements. That's hosted at fedorahosted and changes are discussed o nthe mailing lists. So it's possible to shoehorn that into our existing infrastructure. I bet that both comps.xml and badges would be more efficient on github, though.
The problem with both gh and hosted for comps or for this is that it means those resources need to 'freeze' when we freeze. That's rotten, imo, for comps alone - but if we needed to freeze and were counting on gh being up right before a release? It would be painful to have that dep hung up that way.
I think we cannot rely on external services and I'm not even enamored of relying on fedorahosted b/c, ostensibly, it doesn't freeze.
It doesn't freeze, but thanks to git we *can* just lock it to a commit ID.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 18 Jun 2013 08:49:19 -0400 Stephen Gallagher sgallagh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/17/2013 02:50 PM, seth vidal wrote:
On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi a.badger@gmail.com wrote:
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
I spent some time last week learning ansible and setting up the new badges-backend01.stg. There's a daemon that runs there that reads in a number of yaml files. Each one defines a badge and a set of rules that must pass for the badge to be automatically awarded to a contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo; ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here: http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backend/f...
I need to get them out of the ansible repo. There's going to be too
many of them, and we're going to be iterating on them and changing them often. I was thinking of creating another git repo on lockbox at /git/badges/ for this.
In the longrun though, we want contributors from every corner of the community to contribute new badge ideas (come up with some artwork, make their own yaml definition -- and make it real). We'll have a process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
I agree with the implied nervousness towards this degree of integration.
Repository-wise, I think we need a public repository so, although lockbox can have public repos, something already doing public repos is probably better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements. That's hosted at fedorahosted and changes are discussed o nthe mailing lists. So it's possible to shoehorn that into our existing infrastructure. I bet that both comps.xml and badges would be more efficient on github, though.
The problem with both gh and hosted for comps or for this is that it means those resources need to 'freeze' when we freeze. That's rotten, imo, for comps alone - but if we needed to freeze and were counting on gh being up right before a release? It would be painful to have that dep hung up that way.
I think we cannot rely on external services and I'm not even enamored of relying on fedorahosted b/c, ostensibly, it doesn't freeze.
It doesn't freeze, but thanks to git we *can* just lock it to a commit ID.
Provided it is available. Part of the reason we freeze is so we don't break it :)
- -sv
On Mon, 17 Jun 2013 13:45:09 -0400 Ralph Bean rbean@redhat.com wrote:
...snip...
GitHub's pull request work flow could be a good fit here. It would however set a new precedent for our degree of integration with gh.com. Any thoughts?
Yeah, I could see github's flow being nice here for proposing new badges, etc... but somehow it feels strange to me to directly depend on them in this way.
So, I guess I'd say lets do a lockbox01 repo for now, and reevaluate after freeze is over?
kevin
On Mon, Jun 17, 2013 at 12:47:44PM -0600, Kevin Fenzi wrote:
Yeah, I could see github's flow being nice here for proposing new badges, etc... but somehow it feels strange to me to directly depend on them in this way.
Ricky E had some good points in channel which I'll re-post here for posterity:
re: using github for badges, I think it'd be neat if we could get to that point (but like nirik said, probably something to talk about after the freeze). I'm wondering if we couldn't either 1) Just have a cron pull the badges files from github every few hours, or 2) Set up a tiny POST hook listener from github and pull based on that.
In either of those cases, we have a local copy of the repo, since we're just pulling from github
if github goes down, we still have a copy of it for use in infra.
So, I guess I'd say lets do a lockbox01 repo for now, and reevaluate after freeze is over?
Agreed. I've setup a lockbox01 repo for now.
On 06/17/2013 03:27 PM, Ralph Bean wrote:
On Mon, Jun 17, 2013 at 12:47:44PM -0600, Kevin Fenzi wrote:
Yeah, I could see github's flow being nice here for proposing new badges, etc... but somehow it feels strange to me to directly depend on them in this way.
Ricky E had some good points in channel which I'll re-post here for posterity:
re: using github for badges, I think it'd be neat if we could get to that point (but like nirik said, probably something to talk about after the freeze). I'm wondering if we couldn't either 1) Just have a cron pull the badges files from github every few hours, or 2) Set up a tiny POST hook listener from github and pull based on that.
In either of those cases, we have a local copy of the repo, since we're just pulling from github
if github goes down, we still have a copy of it for use in infra.
So, I guess I'd say lets do a lockbox01 repo for now, and reevaluate after freeze is over?
Agreed. I've setup a lockbox01 repo for now.
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
My input is that if we make use of GitHub, there should be another means of contributing that is at least as effective. I don't like the idea of basing a Fedora structure on GitHub's structure.
-- oddshocks
On Tue, 18 Jun 2013 12:28:45 -0400 David Gay oddshocks@riseup.net wrote:
My input is that if we make use of GitHub, there should be another means of contributing that is at least as effective. I don't like the idea of basing a Fedora structure on GitHub's structure.
Thinking about this... would it be possible to have a interface on the badges web side that allowed submitting new badge ideas?
ie, fill in fields and needed info and it dumps out the rough code of what is needed for that badge and if admins find it good, just add it?
Or even, something that uses datanommer's interface to create the exact query that would be used to award the badge...
I don't know how complex that would end up being...
kevin
On 06/18/2013 12:33 PM, Kevin Fenzi wrote:
On Tue, 18 Jun 2013 12:28:45 -0400 David Gay oddshocks@riseup.net wrote:
My input is that if we make use of GitHub, there should be another means of contributing that is at least as effective. I don't like the idea of basing a Fedora structure on GitHub's structure.
Thinking about this... would it be possible to have a interface on the badges web side that allowed submitting new badge ideas?
ie, fill in fields and needed info and it dumps out the rough code of what is needed for that badge and if admins find it good, just add it?
Or even, something that uses datanommer's interface to create the exact query that would be used to award the badge...
I don't know how complex that would end up being...
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Actually, Threebean and I have discussed this. It is not only possible, but what I plan to do. :) Threebean has made a lot of progress on the yaml files for each badge, and I believe I can develop a form that would generate a yaml file for the badge, so that it can be reviewed and implemented easily.
-- David
infrastructure@lists.fedoraproject.org
-
David Gay -
Falk, Oliver -
Kevin Fenzi -
Ralph Bean -
Seth Vidal -
Stephen Gallagher -
Toshio Kuratomi