We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
The only change in the frozen bits of ansible is:
+++ b/inventory/host_vars/db-qa01.qa.fedoraproject.org @@ -22,6 +22,7 @@ dbs_to_backup: - fakefedorainfra - fakefedorainfra_stg - dev_fakefedorainfra +- execdb_stg - execdb_dev - resultsdb - resultsdb_stg
On Wed, Apr 01, 2015 at 08:47:43AM -0600, Tim Flink wrote:
We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
So you want a stg application to run against a db located on a production environment? Wouldn't it be more logical to have a db-qa01.qa.stg or so?
The only change in the frozen bits of ansible is:
+++ b/inventory/host_vars/db-qa01.qa.fedoraproject.org @@ -22,6 +22,7 @@ dbs_to_backup:
- fakefedorainfra
- fakefedorainfra_stg
- dev_fakefedorainfra
+- execdb_stg
- execdb_dev
- resultsdb
- resultsdb_stg
+1 on the change per say, but see my comment above :)
Pierre
On Wed, 1 Apr 2015 17:16:27 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Apr 01, 2015 at 08:47:43AM -0600, Tim Flink wrote:
We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
So you want a stg application to run against a db located on a production environment?
That's how it's been setup since we first deployed Taskotron - all the dev, stg and prod dbs are on the same host.
Wouldn't it be more logical to have a db-qa01.qa.stg or so?
I can see the argument for doing that but I'm not sure that separating them out would provide enough benefit to justify the overhead of (an) additional database host(s) since the Taskotron bits don't really hit the db very hard. I'm not against the idea of having separate db servers for prod and dev/stg but I'd rather not muck around with that during freeze.
Tim
On Wed, 1 Apr 2015 09:37:50 -0600 Tim Flink tflink@redhat.com wrote:
On Wed, 1 Apr 2015 17:16:27 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Apr 01, 2015 at 08:47:43AM -0600, Tim Flink wrote:
We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
So you want a stg application to run against a db located on a production environment?
That's how it's been setup since we first deployed Taskotron - all the dev, stg and prod dbs are on the same host.
Right. We can split them out later, but I didn't want 3 more instances running so super tiny db's would be seperate.
Wouldn't it be more logical to have a db-qa01.qa.stg or so?
I can see the argument for doing that but I'm not sure that separating them out would provide enough benefit to justify the overhead of (an) additional database host(s) since the Taskotron bits don't really hit the db very hard. I'm not against the idea of having separate db servers for prod and dev/stg but I'd rather not muck around with that during freeze.
Right. I didn't think these very small databases justified new sperate hosts.
I'm +1 to the request for now.
kevin
On Wed, Apr 01, 2015 at 10:06:19AM -0600, Kevin Fenzi wrote:
On Wed, 1 Apr 2015 09:37:50 -0600 Tim Flink tflink@redhat.com wrote:
On Wed, 1 Apr 2015 17:16:27 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, Apr 01, 2015 at 08:47:43AM -0600, Tim Flink wrote:
We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
So you want a stg application to run against a db located on a production environment?
That's how it's been setup since we first deployed Taskotron - all the dev, stg and prod dbs are on the same host.
Right. We can split them out later, but I didn't want 3 more instances running so super tiny db's would be seperate.
Wouldn't it be more logical to have a db-qa01.qa.stg or so?
I can see the argument for doing that but I'm not sure that separating them out would provide enough benefit to justify the overhead of (an) additional database host(s) since the Taskotron bits don't really hit the db very hard. I'm not against the idea of having separate db servers for prod and dev/stg but I'd rather not muck around with that during freeze.
Right. I didn't think these very small databases justified new sperate hosts.
Ok wfm then :) I was just surprise to see a different setup from what I'm used to. But that is also possible because of the connection are allowed between stg and prod on the qa network, right?
Pierre
On Wed, 1 Apr 2015 08:47:43 -0600 Tim Flink tflink@redhat.com wrote:
We had intended to do this before freeze but managed to miss it. One of the upcoming features for taskotron that we've deployed to dev and want to deploy to staging is execdb - task execution tracking for Taskotron.
This requires adding a database to db-qa01.qa which is the db host for the production Taskotron instance but no other changes to production or frozen systems.
Changes applied.
infrastructure@lists.fedoraproject.org