Hi,
This suggestion is linked to our effort to improve the overall RPM user
experience with install, upgrade and erase actions.
Currently on installing or upgrading Apache Brooklyn from RPM the
installer spec starts Apache Brooklyn.
Launching on first install pros and cons.
+ very easy first user experience.
- I expect users to have to tweak their credentials and other details
and having to restart Apache Brooklyn they start using it
Launching on upgrade pros and cons:
- user will not be able to check the GUI immediately.
- If the GUI is not there
then a new user can get bog down in other configurations details and
delay startup additionally.
+ User can be proactive and react better if there is an error with
installing.
Observations from Aled Sage which he made offline :
mysql does NOT start the process -
https://dev.mysql.com/doc/refman/5.5/en/linux-installation-rpm.html
"In MySQL 5.5.5 and later, during a new installation using RPM
packages, the server boot scripts are installed,
but the MySQL server is not started at the end of the
installation, since the status of the server during an unattended
installation is not known."
For upgrade:
"if the MySQL server is running when the upgrade occurs, the
MySQL server is stopped, the upgrade occurs, and the MySQL server is
restarted.
If the MySQL server is not already running when the RPM upgrade
occurs, the MySQL server is not started at the end of the installation."
- Elasticsearch does NOT start the process -
https://github.com/elastic/elasticsearch/issues/3722
MongoDB does NOT start the process -
https://docs.mongodb.com/v3.2/tutorial/install-mongodb-on-red-hat/
RabbitMQ does NOT start the process -
https://www.rabbitmq.com/install-rpm.html
Cassandra does NOT start the process -
https://docs.datastax.com/en/cassandra/2.0/cassandra/install/installRHEL_t.html
A strange behaviour for me which I noticed is
that on CentOS 6 if the process(service) is stopped then when user do
upgrade or erase of the rpm then the action fails.
----
Launching on upgrade.
I'd like to separate this discussion.
Ideally if Apache Brooklyn is started then we would want upgrading to
not interrupt the process.
Putting details here how we can actually implement such behaviour.
The usual way for upgrading Apache Brooklyn is to launch the upgraded
process in a non highAvailability mode
e.g. HOT_BACKUP or similar in order to check persistence
compatibility. (Better to be with a command which exits after it checks
persistence.)
If the above gives no error then user should run the new process in
STAND_BY and then stop the old version.
I am happy to add other points here.
The above scenario may not be easy to implement in rpm.
Before doing an actual upgrade of Apache Brooklyn application files, it
should first extract the rpm contents in a tmp folder and
then use new temp Apache Brooklyn to execute the HOT_BACKUP check.
If that can be implemented then the next step with starting the new
process should be easier.
rpm script should then start the new process in STAND_BY and then stop
the old Apache Brooklyn process.
The discussion is also applicable for .deb or other installers.
--
Kind Regards,
Valentin Aitken!
