[DM-39343] Breaking down all tap schema databases #120
Conversation
| ./build tap-schema-usdf-dev-obstap ../yml/dp02_obscore.yaml ../yml/oga_live_obscore.yaml | ||
| ./build tap-schema-usdf-prod-obstap ../yml/dp02_obscore.yaml | ||
|
|
||
| ./build tap-schema-idfprod-sso ../yml/dp03.yaml |
There was a problem hiding this comment.
The SSOs are fine, but I don't really see a need to have five separate ones, as there is only one back-end DB.
There was a problem hiding this comment.
So that they can have different schemas as we test things and move it around, it doesn't hurt us and it follows the pattern
There was a problem hiding this comment.
which one is the backend DB? i thought we had a bunch?
There was a problem hiding this comment.
which one is the backend DB? i thought we had a bunch?
As far as I know there is currently only one DP0.3 / SSO database - a Postgres DB at SLAC.
It's not wrong to have five identical TAP_SCHEMA builds for this, and I can think of some ways we might use them, conceivably, so I'm not asking you to remove them, but just noting that it's flexibility we might not need.
There was a problem hiding this comment.
And how many environments do you want connected to that SSO database? just usdf-dev? usdf-dev and usdf-prod? I want to know not only which databases exist but which tap services exist
There was a problem hiding this comment.
Based on @fritzm's response on #dm-rsp-team this morning, I think the answer is that we want an SSO-only TAP service on all five of idf-prod, idf-int, idf-dev, usdf-prod, and usdf-dev. All of them will normally point to the same SSO-only Postgres database at USDF, except that during the upcoming USDF outage the IDF RSPs' SSO TAP services will point to the replica of that database recently set up by Dan in the Google cloud. (See Slack for more discussion of the timing of the switchover.)
As I said above, I don't foresee any reason for the TAP_SCHEMA content of the five to be different from each other, but if you want to create five images as a hedge, I don't object.
tap-schema/build-all
Outdated
| ./build tap-schema-usdf-dev-tap ../yml/dp02_dc2.yaml ../yml/dp02_obscore.yaml | ||
| ./build tap-schema-usdf-prod-tap ../yml/dp02_dc2.yaml ../yml/dp02_obscore.yaml | ||
|
|
||
| ./build tap-schema-usdf-dev-obstap ../yml/dp02_obscore.yaml ../yml/oga_live_obscore.yaml |
There was a problem hiding this comment.
This is not correct - "live ObsCore" is on a different back-end (Postgres) DB from DP0.2 ObsCore, which is on Qserv.
Let's call this one "tap-schema-usdf-dev-live-obscore", and it has only ../yml/oga_live_obscore.yaml on it.
There was a problem hiding this comment.
I'm trying to name it after the environment + tap service they are using just to be explicit.
|
So which tap schemas are tap services that we don't want to run? |
|
SSO on idf |
cbanek
force-pushed
the
tickets/DM-39343
branch
2 times, most recently
from
21f9baf
to
1a1b00c
Compare
|
ready for another look |
|
I've looked at this and have a couple of questions for Fritz which I will try to resolve tomorrow (Wednesday) morning. |
|
I've added sso deployments |
No description provided.