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(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
> 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