Description of problem: Any Sat6.1 -> 6.2 upgrade shall deprecate elasticsearch. But every such (successfull) upgrade leaves elasticsearch installed, with its database, and even _running_ (service enabled and running). Please, let upgrade remove that automatically. Upgrade log prints proper instructions (almost complete ones) to really remove elasticsearch, but: - who cares about some info log from a lengthy and _successfull_ upgrade, with tens of "similar" log statements? - why a user must do that action manually? If the steps can be so easily automated? Reasons why we should really remove the [package&service&process&directory]: - first of all, it is very improffesional to deprecate a component but leave it installed and running, with all data in. Esp. after the negative experience with "content host disappeared due to ES" we all have - it takes redundant resources - disk space (low), memory and CPU (medium, it's java) - it might be potential source of security/data breach - running a service with some orphaned but relevant data? Version-Release number of selected component (if applicable): Sat 6.2 How reproducible: 100% Steps to Reproduce: 1. upgrade Sat6.1 to 6.2 2. rpm -qa | grep elasticsearch 3. ps aux | grep elasticsearch 4. ll /var/lib/elasticsearch -R 5. grep elasticsearch /etc/passwd Actual results: 2. elasticsearch-0.90.10-7.el7.noarch 3. elastic+ 1725 0.3 1.1 4382864 154680 ? Sl Nov09 172:32 /bin/java -Xms256m -Xmx256m -Xss256k -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError -Delasticsearch -Des.pidfile=/var/run/elasticsearch/elasticsearch.pid -Des.path.home=/usr/share/java/elasticsearch -cp :/usr/share/java/elasticsearch/lib/elasticsearch-0.90.10.redhat-1.jar:/usr/share/java/lucene4-core.jar:/usr/share/java/lucene4-contrib/*:/usr/share/java/sigar/sigar.jar -Des.config=/etc/elasticsearch/elasticsearch.yml -Des.path.conf=/etc/elasticsearch -Des.path.home=/usr/share/java/elasticsearch -Des.path.logs=/var/log/elasticsearch -Des.path.data=/var/lib/elasticsearch -Des.path.work=/tmp/elasticsearch -Des.path.plugins=/usr/share/java/elasticsearch/plugins org.elasticsearch.bootstrap.ElasticSearch root 16465 0.0 0.0 112652 964 pts/2 R+ 11:49 0:00 grep --color=auto elasticsearch 4. (many files in the directory) 5. elasticsearch:x:992:989:You know, for search:/usr/share/java/elasticsearch:/sbin/nologin Expected results: 2. no such rpm 3. no such java process 4. no such directory 5. no such user. Additional info: /var/log/foreman-installer/satellite.log having: [ INFO 2016-07-30 15:19:53 main] Upgrade Step: elasticsearch_message... [DEBUG 2016-07-30 15:19:53 main] elasticsearch-0.90.10-7.el7.noarch [ INFO 2016-07-30 15:19:53 main] Elasticsearch has been removed as a dependency. The database files can be removed manually with #rm -rf /var/lib/elasticsearch. Some packages are no longer needed and can be removed: #rpm -e ruby193-rubygem-tire tfm-rubygem-tire elasticsearch sigar-java sigar snappy-java lucene4-contrib lucene4 [ INFO 2016-07-30 15:19:53 main] Upgrade Step: add_export_distributor (this may take a while) ... Those steps shall be executed automatically (and removing elasticsearch user).
We discussed this quite a bit upstream and it was decided (with user input) that removing rpms or deleting files was not the proper thing to do automatically on a users system. That said, a) I don't think it should be left in a running state, and should be disabled on startup b) upstream users vs downstream users can have different expectations. If we want to revisit this decision we can, however given how late it is in 6.2's release, I'm hesitant to do that now.
I'll add, that a KCS article with a script to perform this might be the better option. Let users opt-in if they want to do it. This is the approach we are taking with -- https://bugzilla.redhat.com/show_bug.cgi?id=1398068