On Wed, 1 Apr 2015 09:37:50 -0600
Tim Flink <tflink(a)redhat.com> wrote:
On Wed, 1 Apr 2015 17:16:27 +0200
Pierre-Yves Chibon <pingou(a)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
Right. I didn't think these very small databases justified new
I'm +1 to the request for now.