LWSHADOOP-757: Create 7.3.1 SOLR service #32
Conversation
This commit creates a SOLR mpack
| <display-name>solr.in.sh template</display-name> | ||
| <description>This is a template for the solr.in.sh file</description> | ||
| <value> | ||
| # Licensed to the Apache Software Foundation (ASF) under one or more |
There was a problem hiding this comment.
[-1] This solr.in.sh template still needs updated to be more 7.3.1 appropriate
| @@ -0,0 +1,53 @@ | |||
| <?xml version="1.0" encoding="UTF-8" ?> | |||
There was a problem hiding this comment.
[-1] Still need to make sure this solr.xml file is brought in line w/ current 7.3.1 configs.
There was a problem hiding this comment.
(Turns out this didn't diverge at all from what we see in Solr 7.3.1, so no changes were in fact required here.)
| <services> | ||
| <service> | ||
| <name>SOLR</name> | ||
| <version>7.3.1</version> |
There was a problem hiding this comment.
[Q] I chose to base the 7.3.1 service version off of 6.6.2. So I think I should be able to take advantage of that inheritance and really trim down this PR, since many of the files appear identically over in the 6.6.2 directory structure.
But confusingly, I noticed that 5.5.5 and 6.6.2 have a similar relationship. That is common-services/6.6.2 extends common-services/5.5.5, but the two file trees share a good number of files that match identically. Does the “service inheritance” not share as much as I think it does, or am I misunderstanding it? Or are we intentionally trying to not lean on the inheritance too much for some reason?
(The following common-services files all appear to be identical in 5.5.5 and 6.6.2:
➜ SOLR git:(branch_7x) cd src/main/mpack/common-services/SOLR && diff -srq 5.5.5/ 6.6.2/ | grep identical | awk '{print $2}'
5.5.5/package/scripts/service_check.py
5.5.5/package/scripts/setup_solr_cloud.py
5.5.5/package/scripts/setup_solr_hdfs_support.py
5.5.5/package/scripts/setup_solr_ssl_support.py
5.5.5/package/scripts/solr.py
5.5.5/package/scripts/solr_utils.py
5.5.5/package/scripts/status_params.py
5.5.5/package/templates/log4j2.xml
5.5.5/package/templates/solr_metrics_jaas.conf.j2
5.5.5/package/templates/solr_server_jaas.conf.j2
)
There was a problem hiding this comment.
Yes, the packages behaves a bit different from the rest.
The following directories if defined in the current service version replace those from the parent service version:
packages
upgrades
This means the files included in those directories at the parent level will not be inherited. You will need to copy all the files you wish to keep from that directory structure.
The rest of folder are "merge" (there are some setting that we can use, in order to define how they are merge.)
more info here: https://cwiki.apache.org/confluence/display/AMBARI/Service+Inheritance
Prior versions of Solr included a "data_driven" example configset, however this configset was removed during the 7.x release line and is no longer present in 7.3.1. The example-collection configuration referenced this configset, causing the post-startup Solr Check to fail. This commit changes the test collection creation to use the "_default" configset instead.
With the introduction of SOLR-7.3.1, we now have two versions of the SOLR service that (according to their metainfo.xml and mpack.json specs) are meant for HDP-2.6. This commit modifies the service metadata so that SOLR 5.5.5 is used on HDP 2.4, SOLR 6.6.2 is used on HDP 2.5, and SOLR 7.3.1 is used on HDP 2.6.
Each SOLR service version packages up its own solr.in.sh file template. These templates live inside a configuration file called solr-config-env.xml. The 7.3.1 SOLR service version's solr.in.sh contained a comment that referenced a filepath: `<instance_dir>/data`. This made the XML file invalid, as it contained an unclosed/matched XML tag. When Ambari failed to parse this file, it stopped unpacking/initializing the 7.3.1 service version altogether, causing it to be an empty stub. This commit changes the solr.in.sh comment, so that solr-config-env.xml is valid XML once more.
This commit creates a SOLR mpack