integration with OneData

[TomasKulhanek]

• [x] backend support, DONE
• [x] frontend support, DONE
• [ ] test, optionally unit test, asked for storage on https://onezone.cloud.cnaf.infn.it
• [ ] add documentation, user, developer
• [ ] submit to production - portal.west-life.eu
• [ ] VF_ALLOW_ONEDATA env. variable will enable OnedataProvider - By default disabled as onedata have not released stable version yet

[pandreetto]

The oneclient is a requirement for the integration. Since there are several compatibility problems between oneclient and oneprovider, it is strongly reccomended to install the same release of the service:

yum -y localinstall http://packages.onedata.org/yum/centos/7x/x86_64/oneclient-18.02.0.rc8-1.el7.centos.x86_64.rpm

[TomasKulhanek]

• I commented AdjProvInfo, alias defined by user interface, or by intermittent API
• oneclient process seems to timeout, nothing in mounted directory, no logs produced

[pandreetto]

I'm preparing a new PR for handling the alias parameter. Concerning the timeout of the oneclient I've got to investigate. Please remember that you've got to install the same version of the onedata suite both on server and client side. The problem that I have now is the TLS support and the connections to the Oneprovider. The callback that should verify (or in our case to ignore) the Oneprovider certificate is not called anymore and I don't know why. Any query to the Oneprovider API service fails due to TLS verification error.

[TomasKulhanek]

I force alias to be defined by user or to be generated before it's delegated to OnedataProvider. I recommend not to use AdjProvInfo as it doesn't match concept of other provider implementation. Or do you have good reason to keep it and override the alias value?

As this becomes more serious than I expected. I'd recommend 1) either to give up the integration effort for the following reasons stated already above

• dependency on third party libraries which are not stable enough
• client and server seems to be tightly coupled by exact version number, it's onerous effort to maintain several 'oneclient' version on VF instance to match possible different version of 'oneserver' by different providers.

2) or limit the supported onedata to exact version installed on the server and limit the usage on INFN instance - thus givin choice of hostname to only 'https://onezone.cloud.cnaf.infn.it'

[pandreetto]

No problem with AdjProvInfo, I'm going to remove it. Onedata is not yet stable enough, we know it, that's the reason why we consider the integration with VF as a prototype, at least for the moment. The integration will be "production ready" only when a final release of Onedata is available, and we will support only the stable release. Can we devise a way to disable the plugin and re-activate it only if an env. variable, or something like that, is defined?

[TomasKulhanek]

Thanks,

1) AdjProvInfo - I already commited to master branch commented version - no action needed.

2) I have VF_ALLOW_FILESYSTEM, I will introduce VF_ALLOW_ONEDATA and put it into ProviderFactory. No changes need to be done in other classes.

[marcoverl]

Hi there, could we anyway go ahead with the option 2 ( limit the supported onedata to exact version installed on the server and limit the usage on INFN instance - thus giving choice of hostname to only 'https://onezone.cloud.cnaf.infn.it') for the implementation in portal.west-life.eu, even with a disclaimer that is a experimental feature?

[pandreetto]

The problem I have is described here In the thread there's an interesting link to stackoverflow. If I'm not able to fix the problem I will call curl from the plugin, so we can handle the trusted certificates via system truststores.