gerlowskija commented on code in PR #826: URL: https://github.com/apache/solr/pull/826#discussion_r867924072
########## solr/modules/aws-secret-provider/README.md: ########## @@ -0,0 +1,80 @@ +Apache Solr - AWS Secret Provider +=========================== + +An implementation of `SecretCredentialsProvider` that pulls Zookeeper credentials from an AWS Secret Manager. + +This plugin uses the [default AWS credentials provider chain](https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/credentials.html), so ensure that your credentials are set appropriately (e.g., via env var, or in `~/.aws/credentials`, etc.). + +## Usage + +- To enable this feature copy the jar files in `modules/aws-secret-provider/lib` to `SOLR_INSTALL/server/solr-webapp/webapp/WEB-INF/lib/` and add follow the below steps before restarting Solr. Review Comment: > The issue here is that ZK connection to load solr.xml is called before the modules are loaded True, if solr.xml lives in ZooKeeper. But it can also live on-disk on each Solr node. When solr.xml lives on-disk, the CNFE shows up later, on CoreContainer loading (after NodeConfig has been fetched/parsed): ``` at org.apache.solr.common.cloud.SolrZkClient.<init>(SolrZkClient.java:206) org.apache.solr.common.SolrException: java.lang.IllegalArgumentException: Could not instantiate the SecretCredentialProvider class with name: org.apache.solr.secret.zk.AWSSecretCredentialsProvider at org.apache.solr.common.cloud.SolrZkClient.<init>(SolrZkClient.java:206) ~[?:?] at org.apache.solr.cloud.ZkController.<init>(ZkController.java:490) ~[?:?] at org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:142) ~[?:?] at org.apache.solr.core.CoreContainer.load(CoreContainer.java:742) ~[?:?] at org.apache.solr.servlet.CoreContainerProvider.createCoreContainer(CoreContainerProvider.java:376) ~[?:?] ``` I wasn't terribly concerned with the case where the CNFE occurs trying to load solr.xml from ZK. Primarily because the problem pre-exists your PR: users will hit that today in released versions of Solr if they bring their own ZkACLProvider implementation etc. And secondarily because IMO it seems reasonable to say that if you want to customize how Solr connects to ZK, you need to put your configuration for that on-disk so that Solr can read it before ZK-conn time. I'd sleep just fine at night if we just "punted" on that problem and documented the limitation. That said, if you feel strongly that you want to solve the problem for all cases (i.e. where solr.xml lives in ZK), we can try that. But Solr folks (not me unfortunately, but others) have put a lot of thought into Solr's classloader setup to support the many ways that Solr supports loading "extra" jars (contribs/modules, "plugins", blob store entries, etc.). That's not to say that we _can't_ introduce a new classloader to solve our problem here, but it'll take some very careful testing and probably some review by someone more familiar with Solr's classloader code than I am. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
