Refactor Swift storage driver properties / properties getter

[carlosmcgregor]

The Swift storage driver loads properties from swift.properties with every action executed by the driver (e.g. when creating a temp url). The getter itself, which loads the file, is located in these lines.

Loading properties would be better suited for a class like (SystemConfig.java)[https://github.com/IQSS/dataverse/blob/develop/src/main/java/edu/harvard/iq/dataverse/util/SystemConfig.java]. Please correct me if this would not be the best place!

This also opens a bigger argument on whether swift.properties should be on a separate file than domain.xml. If not, then we could forgo the previously mentioned refactoring of the getter and move ahead with loading the configurations with System.getProperty() (à la S3 driver).

[pdurbin]

@carlosmcgregor thank you for popping into IRC the other day to discuss this idea ( http://irclog.iq.harvard.edu/dataverse/2019-01-11#i_84497 ) and for creating this issue. Since you've already made improvements to the Swift driver in pull request #5356 you're in a better position than I am to judge how to make additional improvements, such as the performance optimizations you're proposing. The options as I understand them are:

• Status quo: leave the config in swift.properties
• Move config to JVM options (domain.xml)
• Move the config to database settings

Are you interested in creating a pull request? Do you you want some more opinions from other Dataverse developers, first? If so, I can pull this issue into the code review column at https://waffle.io/IQSS/dataverse to bring attention to it during our daily standup. Please let us know. Thanks!

[carlosmcgregor]

Hello, @pdurbin ! Thank you for outlining all the options so clearly :D I am gravitating between the first two options and will be working on the performance optimization. I am expecting to do a pull request before the end of the week.

[pdurbin]

@carlosmcgregor sounds good but the first option, "status quo", would be no change and no pull request, right?

@landreev do you have any opinions about moving the Swift config to JVM options?

[carlosmcgregor]

@pdurbin for "status quo", I was thinking about retaining swift.properties but moving the properties getter somewhere else so that the file is not accessed on every transaction.

[pdurbin]

Oh! I understand, I think. A behind-the-scenes optimization. Maybe the doc change would mention that if you need to update swift.properties you have to restart Glassfish? It sounds like right now the moment you change the file the new settings are live.

[carlosmcgregor]

My apologies, @pdurbin ~! I studied the issue further and noticed such optimization would not be possible whilst keeping a swift.properties file. Hence, we could load all properties into domain.xml.

If credentials are a security concern, we could keep all credential data in a swift.properties file, thus giving flexibility if you were to, at one point, secure that file in some other place (similar to what the S3 driver does standard, having all credentials located at ~/), and move all other regular settings like Swift URL to domain.xml. This would also allow for asadmin changes to these values and create greater parallelism between the way S3 and Swift is administered in Dataverse.

[pdurbin]

@carlosmcgregor for storage of credentials, please take a look a the "create-password-alias" work that was recently merged in pull request #5487. Thanks!