load.bety.sh not honoring PG_OPT in all cases

[max-zilla]

https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh

I can use -p with load.bety.sh to pass in my parameters for the psql host - e.g. in a docker environment I will want to specify -h, -p, and -U for the psql calls"

./load.bety.sh -p "-h $PG_PORT_5432_TCP_ADDR -p $PG_PORT_5432_TCP_PORT -U bety"

There is a var in this script called PG_OPT that allows one to pass these in, but it is absent from several of the psql calls in the file: https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L207 https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L229 & line after https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L233 & line after

Is there a specific reason these were omitted? It's causing trouble when I want to start BETY inside a docker container and point it at a Postgres db in another container - the load script fails when it encounters those psql commands without PG_OPT as it's trying to default to localhost and complains:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

[max-zilla]

@gsrohde @robkooper any thoughts?

[gsrohde]

If you set host to '/tmp' instead of the default localhost, that might work. I.e., add "-h /tmp".

[gsrohde]

Sorry, it doesn't look like you're using a local host. But I don't quite understand the call syntax you're using and why you have quote (") marks where you do.

[max-zilla]

In the args for load.bety.sh I saw this:

-p additional psql command line options, default is empty"

My intent was to pass along the -h host, -p port and -U user parameters to the psql command line calls within the script. Am I misunderstanding?

the two environmental variables are a docker thing, it basically translates to:

./load.bety.sh -p "-h 172.17.0.2 -p 5432 -U bety"

[gsrohde]

Is 172.17.0.2 the machine containing the virtual machine in which the docker script is running?

[max-zilla]

It's the docker container that's running the postgres instance. I am attempting to run this script from another docker container which is linked to the pg one.

It should work. At the terminal in the "bety" container (as opposed to the postgres container):

psql

returns the same error that host does not exist.

psql -h 172.17.0.2 -p 5432 -U bety --password

Successfully connects me to the database and I can create tables, etc.

I intend to pass those arguments into load.bety.sh so it connects to the proper host as well.

[robkooper]

all use of psql should have the PG_OPT flags.

[max-zilla]

This issue is closed, but a similar problem exists with the -o option (OWNER). psql calls shoudl honor the owner flag like line 230:

psql ${PG_OPT} -U ${OWNER} -q -d "${DATABASE}" -c "CREATE SCHEMA public"

However many of the calls omit -U ${OWNER}:

if ! psql ${PG_OPT} -lqt | cut -d \| -f 1 | grep -w "${DATABASE}" > /dev/null ; then

https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L207 https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L229 https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L233 & line after https://github.com/PecanProject/pecan/blob/master/scripts/load.bety.sh#L291

As it is, I still encounter this error even though I pass -o into the ./update-bety.sh script (and thus load-bety.sh):

psql: FATAL:  role "root" does not exist

[gsrohde]

@max-zilla I think the role "root" does not exist error comes from when psql tries to connect. If you are running the update-bety.sh script as root and aren't using the -U option, then it tries to connect to the database as role "root", which usually doesn't exist (and probably shouldn't).

You can use the -p option to the script to pass options to psql—-p "-U bety" (or maybe some other user name) is what you want. But there is an error in how update-bety.sh passes options through to load.bety.sh, so until I fix this, you will need to run load.bety.sh directly (once it has been downloaded). I'll make myself an issue for this.

I'm not sure why load.bety.sh has the -U option on one psql call and not on the others. @robkooper Is this the way it is supposed to be?

[max-zilla]

Thanks @robkooper for fixing.