Jupiter 10.5.0 mysql empty host user removal

[kobimichaeli]

@tan-tan-kanarek 1st commit, please review it.

[tan-tan-kanarek]

Instead of 'use mysql', you could add mysql as last argument to the mysql command, but since you use mysql.user, you just don't need it.

[jessp01]

@kobimichaeli,

The reason I do not wish to do this for the user is that we are messing with tables that were not created by us, i.e the mysql.user table.
In the guide, we ask to run mysql_secure_installation which removes these lines and is supplied by MySQL package.
Did you run this script before starting the install? if so, we should try to understand why it did not remove these records and the test DB..

Thanks,

[jessp01]

@kobimichaeli, can you please reply?

[jessp01]

Just so that my discussion with Kobi is documented, here is our mail exchange:

Kobi:
The reason for the change (apart from the fact that I didn’t use the mysql_secure_installation correctly J ) is that there is an
effort to make a fully automated install tool which will receive a premade answer file,

and install a single machine and later a multi-server installation.

We are trying to achieve this goal in order to create an automated testing process which will be able to install and roll back a
snapshot on a set of VM machines without any user intervention.

What I’ve been assigned to do is use your install scripts and install a machine using them. Since (at the moment) there is no
danger of damaging any user DB, there is no danger of performing the removal.

I’ve managed to get around the mysql_secure_installation’s problem of being interactive use only, so there is no need for the
change I’ve made.

I will not proceed with the Kaltura-db-config.sh’s change since there is no current need for it.The reason for the change (apart from the fact that I didn’t use the mysql_secure_installation correctly J ) is that there is an
effort to make a fully automated install tool which will receive a premade answer file,

and install a single machine and later a multi-server installation.

We are trying to achieve this goal in order to create an automated testing process which will be able to install and roll back a
snapshot on a set of VM machines without any user intervention.

What I’ve been assigned to do is use your install scripts and install a machine using them. Since (at the moment) there is no
danger of damaging any user DB, there is no danger of performing the removal.

I’ve managed to get around the mysql_secure_installation’s problem of being interactive use only, so there is no need for the
change I’ve made.

I will not proceed with the Kaltura-db-config.sh’s change since there is no current need for it.

Jess:
This already exists, see:
https://github.com/kaltura/platform-install-packages/tree/Jupiter-10.5.0/vagrant

While it is about vagrant, you can use the same method as here:
https://github.com/kaltura/platform-install-packages/blob/Jupiter-10.5.0/vagrant/kaltura-install.sh
for non vagrant installs as well.

Apart from the MySQL, it is ALL automated with an ans file already, see doc:
https://github.com/kaltura/platform-install-packages/blob/Jupiter-10.5.0/doc/kaltura.template.ans

It has to be this way because we support fully automated deployments using Chef.

I am closing the request but do let me kow if you have more questions