You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When running on machines that aren't operations at Utah, there are no appropriate default profiles. E.g., mwm.sdss.org
Describe the solution you'd like
Add a profile? Is it problematic to use *.sdss.org as the domain?
Describe alternatives you've considered
Currently users provide credentials manually...
The text was updated successfully, but these errors were encountered:
I think the problem with that it that it assumes that everybody on a Utah machine wants to connect to sdss5db on operations. That may be true (?) but maybe not (?).
It may be better to just document better the use of a profile, i.e.,
but if everybody agrees that sdss5db on operations is going to be 95% of the use-case, then yes, adding a profile sounds ok. Probably can be done by expanding the domain of the operations profile to include anything at Utah.
I think it's more than 95%. astra, targetdb, catalogdb, opsdb; basically everything except slurm and the old platedb/apogeeqldb is in sdss5db on operations. I don't think it's an issue for slurm?
Is your feature request related to a problem? Please describe.
When running on machines that aren't operations at Utah, there are no appropriate default profiles. E.g., mwm.sdss.org
Describe the solution you'd like
Add a profile? Is it problematic to use *.sdss.org as the domain?
Describe alternatives you've considered
Currently users provide credentials manually...
The text was updated successfully, but these errors were encountered: