On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Patches attached.
Would be good to get an ack from Tim Flink or other qa folks before applyiing, just to make sure everything is correct. ;)
kevin
I agree, I'd expected these would all be reviewed by someone that's doing more that just reading and digging and really know what is going on with each system.
Thanks,
Dave Shier
On 11/27/2015 02:06 PM, Kevin Fenzi wrote:
On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Patches attached.
Would be good to get an ack from Tim Flink or other qa folks before applyiing, just to make sure everything is correct. ;)
kevin
infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Comments inline for the dev patch, stg and prod have similar comments.
+csi_security_category: Moderate +csi_primary_contact: #fedora-admin infrastructure@fedoraproject.org +csi_purpose: Run automated tasks, such as builds on fedora components and report results of those task runs.
Taskotron does not run builds. I suppose it could but that would likely overlap with Koji and/or copr.
A better way to put it would be: Runs automated tasks against Fedora components triggered by fedmsgs and reports results of those tasks to resultsdb.
The difference between the three systems is:
* dev is where we try out new features, often before they're ready for general consumption
* stg is very close to prod and is used to verify that changes work before they're deployed to prod
* prod is the production system which most folks interface with
+csi_relationship: | + +The system is made up of several components: + +- trigger + +- task execution system + this is a master/slave system, currently using buildbot + +- results storage (in resultsdb) + +- mirror task git repos
I'm a little fuzzy on what's supposed to be in this field. The taskotron-{dev,stg,prod} playbooks are responsible for the following parts of the Taskotron system:
* run the trigger program which listens for fedmsgs which kick off tasks
* run the buildmaster
* host the static landing page at taskotron.fp.o
+- requires access to the git mirror(s), builders (koji, copr) and +resultsdb
This is not quite right. A more accurate description of the dependencies would be:
requires access to kojihub, bodhi, fedmsg hub, dist-git and the upstream task repositories.
Are we planning to fill in the CSI vars for the other Taskotron related playbooks or is this meant to describe the system in its entirety?
Thanks for getting this started,
Tim
Tim-
Thanks for the detailed reply! I will review and make the adjustments.
In the list there are entries for the below that are flagged as needing group vars updates:
taskotron-dev taskotron-dev-client-hosts taskotron-dev-clients taskotron-prod taskotron-prod-clients taskotron-stg taskotron-stg-clients
I planned on updating all of those, but figured I would start with this piece. If there are other pieces that are not in the list let me know and I will add them to my list of vars to update.
Dave Shier / odin2016
On 12/02/2015 10:14 AM, Tim Flink wrote:
On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Comments inline for the dev patch, stg and prod have similar comments.
+csi_security_category: Moderate +csi_primary_contact: #fedora-admin infrastructure@fedoraproject.org +csi_purpose: Run automated tasks, such as builds on fedora components and report results of those task runs.
Taskotron does not run builds. I suppose it could but that would likely overlap with Koji and/or copr.
A better way to put it would be: Runs automated tasks against Fedora components triggered by fedmsgs and reports results of those tasks to resultsdb.
The difference between the three systems is:
dev is where we try out new features, often before they're ready for general consumption
stg is very close to prod and is used to verify that changes work before they're deployed to prod
prod is the production system which most folks interface with
+csi_relationship: |
+The system is made up of several components:
+- trigger
+- task execution system
- this is a master/slave system, currently using buildbot
+- results storage (in resultsdb)
+- mirror task git repos
I'm a little fuzzy on what's supposed to be in this field. The taskotron-{dev,stg,prod} playbooks are responsible for the following parts of the Taskotron system:
run the trigger program which listens for fedmsgs which kick off tasks
run the buildmaster
host the static landing page at taskotron.fp.o
+- requires access to the git mirror(s), builders (koji, copr) and +resultsdb
This is not quite right. A more accurate description of the dependencies would be:
requires access to kojihub, bodhi, fedmsg hub, dist-git and the upstream task repositories.
Are we planning to fill in the CSI vars for the other Taskotron related playbooks or is this meant to describe the system in its entirety?
Thanks for getting this started,
Tim
infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
On Wed, 2 Dec 2015 10:22:39 -0500 David Shier davidjshier@gmail.com wrote:
Tim-
Thanks for the detailed reply! I will review and make the adjustments.
In the list there are entries for the below that are flagged as needing group vars updates:
taskotron-dev taskotron-dev-client-hosts taskotron-dev-clients taskotron-prod taskotron-prod-clients taskotron-stg taskotron-stg-clients
I planned on updating all of those, but figured I would start with this piece. If there are other pieces that are not in the list let me know and I will add them to my list of vars to update.
resultsdb-* are also part of taskotron.
I'd suggest skipping the taskotron-*-clients playbooks, they're not long for this earth and unless there's a huge urgency in getting 100% coverage with csi vars, I don't think it'd be worth the time.
Tim
Dave Shier / odin2016
On 12/02/2015 10:14 AM, Tim Flink wrote:
On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Comments inline for the dev patch, stg and prod have similar comments.
+csi_security_category: Moderate +csi_primary_contact: #fedora-admin infrastructure@fedoraproject.org +csi_purpose: Run automated tasks, such as builds on fedora components and report results of those task runs.
Taskotron does not run builds. I suppose it could but that would likely overlap with Koji and/or copr.
A better way to put it would be: Runs automated tasks against Fedora components triggered by fedmsgs and reports results of those tasks to resultsdb.
The difference between the three systems is:
- dev is where we try out new features, often before they're
ready for general consumption
- stg is very close to prod and is used to verify that changes
work before they're deployed to prod
- prod is the production system which most folks interface with
+csi_relationship: |
+The system is made up of several components:
+- trigger
+- task execution system
- this is a master/slave system, currently using buildbot
+- results storage (in resultsdb)
+- mirror task git repos
I'm a little fuzzy on what's supposed to be in this field. The taskotron-{dev,stg,prod} playbooks are responsible for the following parts of the Taskotron system:
run the trigger program which listens for fedmsgs which kick off tasks
run the buildmaster
host the static landing page at taskotron.fp.o
+- requires access to the git mirror(s), builders (koji, copr) and +resultsdb
This is not quite right. A more accurate description of the dependencies would be:
requires access to kojihub, bodhi, fedmsg hub, dist-git and the upstream task repositories.
Are we planning to fill in the CSI vars for the other Taskotron related playbooks or is this meant to describe the system in its entirety?
Thanks for getting this started,
Tim
infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
Thanks, Tim. I'll skip clients and add resultsdb* to my list. I hope to get to poke these tonight. Built a new box last night so still moving in. :)
Sent using Boxer
On Dec 2, 2015 10:42 AM, Tim Flink tflink@redhat.com wrote:
On Wed, 2 Dec 2015 10:22:39 -0500 David Shier davidjshier@gmail.com wrote:
Tim-
Thanks for the detailed reply! I will review and make the adjustments.
In the list there are entries for the below that are flagged as needing group vars updates:
taskotron-dev taskotron-dev-client-hosts taskotron-dev-clients taskotron-prod taskotron-prod-clients taskotron-stg taskotron-stg-clients
I planned on updating all of those, but figured I would start with this piece. If there are other pieces that are not in the list let me know and I will add them to my list of vars to update.
resultsdb-* are also part of taskotron.
I'd suggest skipping the taskotron-*-clients playbooks, they're not long for this earth and unless there's a huge urgency in getting 100% coverage with csi vars, I don't think it'd be worth the time.
Tim
Dave Shier / odin2016
On 12/02/2015 10:14 AM, Tim Flink wrote:
On Thu, 26 Nov 2015 17:17:46 -0500 David Shier davidjshier@gmail.com wrote:
Comments inline for the dev patch, stg and prod have similar comments.
+csi_security_category: Moderate +csi_primary_contact: #fedora-admin infrastructure@fedoraproject.org +csi_purpose: Run automated tasks, such as builds on fedora components and report results of those task runs.
Taskotron does not run builds. I suppose it could but that would likely overlap with Koji and/or copr.
A better way to put it would be: Runs automated tasks against Fedora components triggered by fedmsgs and reports results of those tasks to resultsdb.
The difference between the three systems is:
- dev is where we try out new features, often before they're
ready for general consumption
- stg is very close to prod and is used to verify that changes
work before they're deployed to prod
- prod is the production system which most folks interface with
+csi_relationship: |
+The system is made up of several components:
+- trigger
+- task execution system
- this is a master/slave system, currently using buildbot
+- results storage (in resultsdb)
+- mirror task git repos
I'm a little fuzzy on what's supposed to be in this field. The taskotron-{dev,stg,prod} playbooks are responsible for the following parts of the Taskotron system:
run the trigger program which listens for fedmsgs which kick off tasks
run the buildmaster
host the static landing page at taskotron.fp.o
+- requires access to the git mirror(s), builders (koji, copr) and +resultsdb
This is not quite right. A more accurate description of the dependencies would be:
requires access to kojihub, bodhi, fedmsg hub, dist-git and the upstream task repositories.
Are we planning to fill in the CSI vars for the other Taskotron related playbooks or is this meant to describe the system in its entirety?
Thanks for getting this started,
Tim
infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
_______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraprojec...
infrastructure@lists.fedoraproject.org