Closed joelbrownstein closed 1 year ago
I added:
pipelines:
host: pipelines.sdss.org
port: 5432
domain: pipelines.sdss.*
Does this work? I think it might. But there are some known issues with the default profiles at Utah; many of us have added manual connection strings in our code because the automatic config doesn't get picked up correctly. Every now and again I think about trying to fix that...
I think that works, but I don't seem to be able to ssh to the pipelines machine (but can connect to the DB there). If I use the same profiles as operations
but tell it to point to the pipelines DB and leave the user empty it seems to connect with my Linux user.
@johndonor3 can you test this if you can ssh to pipelines?
@albireox I requested CHPC allow your unid to ssh to pipelines on INC1550169.
Thanks @joelbrownstein I've seen the ticket.
Something that doesn't exactly work as expected is that if you're in the operations machine it will, as expected, load the operations
profile. But if you then do
database.set_profile("pipelines")
or
database.connect(host="pipelines.sdss.org", user=None)
it will still fail because it tries to connect using sdss_user
, inherited from the operations
profile. I'll look into that.
I am still able to ssh to pipelines (and psql from interactive nodes). CHPC has decided to only manually allow access I believe (which seems fine, at least for now), so the ticket should resolve your access issue.
I've made a change in fbfa151 so that if you do database.set_profile('pipelines')
from, for example, operations
, it will connect correctly using your username.
I think this should all work now, but if somebody with access to pipelines
can test form there that importing the database connects correctly when logged from there, I think we are ready (and maybe we should tag).
I've tested it on mwm and operations, as far as I can tell it seems to be working as expected. We should update the auto-generated schemas before tagging; I noticed targetdb at least is a little too out of date.
0.6.4 has been tagged and pushed to pypi (not sure if the release workflow worked as intended?) I think we can close this issue?
The user for this connection should be "my unid" instead of the generic sdss user, so how do we adapt:
for this usecase? ie can we just not include
with no mention of sdss_user, or do we need to add something dynamic which pass the output of something like get_username()?