-
Notifications
You must be signed in to change notification settings - Fork 493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
7980 enhanced dsd #8915
7980 enhanced dsd #8915
Conversation
…IG. IQSS#7980 Previously, with Dataverse software 5.3, the option to configure the database connection has been moved into the codebase. Admins can set details via MicroProfile Config. With updating to Payara 5.2021.4, we can provide default values for the connection details. Before, this had been tried with adding them to META-INF/microprofile-config.properties. However, this is not possible due to the timing of resource creation in the application server vs. reading the properties file. IQSS#7980
As requested by @pdurbin, the long list was quite overwhelming. It's now damped down to 12 options in 3 subsubsections of the docs.
The avoid hacky parameter additions via the database name, this commit adds support for adding parameters to the JDBC URL. It defaults to empty (no parameters).
With the addition of the advanced (but proprietary, Payara-only) settings for database connection monitoring, the non-present default for connection validation triggered unnecessary log clutter. Adding an empty default makes these go away and is inline with the default of Payara.
5144d16
to
8350af2
Compare
sizing: Waiting on Oliver input. He is out today. |
Phil is going to talk with Oliver to see if this can be lowered in priority in the community column |
I've just merged latest That said, yes, it may move down the column. I have no urgent business requiring this ATM. |
You know what? Based on comments by @landreev and @donsizemore in the issue regarding the usefulness of By the way, there's a failing test but I suspect it's unrelated:
|
Pdurbin reviewed and sized. Moving to sprint ready column. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
The most immediate real world use case for this PR seems to be sslmode=require
(see the issue this PR closes) so I mentioned this in the docs.
I did some cursory testing but didn't test the new default database name and user (both "dataverse") though I left a comment about how we could probably test this.
I love the new rst table format, by the way. Seems much easier than keeping the correct number of spaces here or there!
@@ -263,6 +263,153 @@ As for the "Remote only" authentication mode, it means that: | |||
- ``:DefaultAuthProvider`` has been set to use the desired authentication provider | |||
- The "builtin" authentication provider has been disabled (:ref:`api-toggle-auth-provider`). Note that disabling the "builtin" authentication provider means that the API endpoint for converting an account from a remote auth provider will not work. Converting directly from one remote authentication provider to another (i.e. from GitHub to Google) is not supported. Conversion from remote is always to "builtin". Then the user initiates a conversion from "builtin" to remote. Note that longer term, the plan is to permit multiple login options to the same Dataverse installation account per https://github.com/IQSS/dataverse/issues/3487 (so all this talk of conversion will be moot) but for now users can only use a single login option, as explained in the :doc:`/user/account` section of the User Guide. In short, "remote only" might work for you if you only plan to use a single remote authentication provider such that no conversion between remote authentication providers will be necessary. | |||
|
|||
|
|||
|
|||
Database Persistence |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs are great but I wonder if they should be moved to "Advanced Installation" because the default database setup works fine and the list of steps before "going live" is getting longer and longer. We can defer this doc change for now. I created a dedicated issue for later:
* - dataverse.db.parameters | ||
- Connection parameters, see `Postgres JDBC docs <https://jdbc.postgresql.org/documentation/head/connect.html>`_ | ||
Note: you don't need to provide the initial "?". | ||
- *Empty string* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried putting the following in domain.xml...
<jvm-options>-Ddataverse.db.parameters=sslmode=require</jvm-options>
... and it seems to have worked. Dataverse failed to deploy and I get errors like this in server.log:
Connection could not be allocated because: The server does not support SSL.
Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
Exception while invoking class org.glassfish.ejb.startup.EjbApplication start method
javax.ejb.EJBException: javax.ejb.CreateException: Initialization failed for Singleton StartupFlywayMigrator
...
Caused by: org.flywaydb.core.internal.exception.FlywaySqlException: Unable to obtain connection from database: Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
SQL State : null
Error Code : 0
Message : Error in allocating a connection. Cause: Connection could not be allocated because: The server does not support SSL.
* - dataverse.db.user | ||
- The PostgreSQL user name to connect with. | ||
- | ``dataverse`` | ||
| (installer sets to ``dvnapp``) | ||
* - dataverse.db.password | ||
- The PostgreSQL users password to connect with. | ||
|
||
**Please note the safety advisory above.** | ||
- *No default* | ||
* - dataverse.db.name | ||
- The PostgreSQL database name to use for the Dataverse installation. | ||
- | ``dataverse`` | ||
| (installer sets to ``dvndb``) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how to see that the default database user and database are "dataverse".
To deploy this branch I used scripts/dev/dev-rebuild.sh
which has the names the installer uses hard coded:
DB_NAME=dvndb
DB_USER=dvnapp
I guess I could try changing that script to this...
DB_NAME=dataverse
DB_USER=dataverse
... and then deleting these lines from domain.xml:
<system-property name="dataverse.db.user" value="dvnapp"></system-property>
<system-property name="dataverse.db.name" value="dvndb"></system-property>
That is, without these system properties configured, it sounds like the default database user and database name will be "dataverse".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Sorry, but for container environments it really is common practice to use the application name for the database name. As the installer sets this explicitly for any installation out there, folks should be fine.
@poikilotherm Can you refresh from develop? Getting flyway errors on deployment. Thanks! |
@kcondon done! Refreshed! Ahhh. |
What this PR does / why we need it:
Create real defaults for the database connection, enable configuring advanced settings, add docs.
Which issue(s) this PR closes:
Closes #7980
Special notes for your reviewer:
Only in a few occasions people might have hit the regression.
Suggestions on how to test this:
asadmin create-system-properties "dataverse.db.log-jdbc-calls=true"
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Nope.
Is there a release notes update needed for this change?:
🔋 included.
Additional documentation:
None.