Github user simonellistonball commented on a diff in the pull request:
https://github.com/apache/metron/pull/1111#discussion_r212275406
--- Diff:
metron-interface/metron-alerts-host/src/main/scripts/metron-alerts.sh ---
@@ -0,0 +1,55 @@
+#!/usr/bin/env bash
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+#
+
+if [ -z "${METRON_SSL_PASSWORD}" ]; then
+ echo "METRON_SSL_PASSWORD unset."
+fi
+
+METRON_VERSION=${project.version}
+METRON_HOME="${METRON_HOME:-/usr/metron/${METRON_VERSION}}"
+METRON_SYSCONFIG="${METRON_SYSCONFIG:-/etc/default/metron}"
+
+echo "METRON_VERSION=${METRON_VERSION}"
+echo "METRON_HOME=${METRON_HOME}"
+echo "METRON_SYSCONFIG=${METRON_SYSCONFIG}"
+
+if [ -f "$METRON_SYSCONFIG" ]; then
+ echo "METRON_SYSCONFIG=${METRON_SYSCONFIG}"
+ set -a
+ . "$METRON_SYSCONFIG"
+fi
+
+echo "METRON_SPRING_PROFILES_ACTIVE=${METRON_SPRING_PROFILES_ACTIVE}"
+
+METRON_CONFIG_LOCATION="
--spring.config.location=classpath:/application.yml,$METRON_HOME/config/alerts_ui.yml"
+echo "METRON_CONFIG_LOCATION=${METRON_CONFIG_LOCATION}"
+METRON_SPRING_OPTIONS+=${METRON_CONFIG_LOCATION}
--- End diff --
They're actually in different environments, so didn't feel the need to
change the convention. These scripts take all their environment from Ambari
launchers in a subsequent PR, rather than the /etc/defaults approach, so there
is no actual collision. I can see an argument for changing them all for
clarity, but could also see the argument for consistency in the context of
potentially growing number of services like this.
---
