SatelliteQE / robottelo-ci

Jenkins jobs configuration files to be used to run Robottelo against Satellite 6.
GNU General Public License v3.0
14 stars 45 forks source link

add --force option to installer job to allow re-installation on existing systems. #318

Open rochacbruno opened 8 years ago

rochacbruno commented 8 years ago

If you have satellite currently installed and wants to re-install you can do manually using:

$ katello-remove
$ yum install -y satellite

and then this long command

$ satellite-installer --scenario satellite  -v --foreman-proxy-tftp-servername="FQDN" --foreman-proxy-tftp="true" --foreman-proxy-dns-zone="FQDN" --katello-proxy-password="secret" --katello-proxy-port="3128" --katello-proxy-url="FQDN" --foreman-proxy-dhcp="true" --foreman-proxy-dns="true" --foreman-proxy-register-in-foreman="true" --foreman-admin-password="changeme" --capsule-puppet="true" --foreman-proxy-puppetca="true" --foreman-proxy-dns-interface="virbr1" --foreman-proxy-dhcp-interface="virbr1" --katello-proxy-username="admin" --foreman-proxy-dns-forwarders="IPADDRESS" --foreman-proxy-dns-forwarders="IPADDRESS" --foreman-proxy-dns-forwarders="IPADDRESS" --foreman-proxy-dns-forwarders="IPADDRESS"

Because of the long command above, using satellite6 installer job on jenkins is useful, but it is currently failing because it misses --force option. (the error says you are trying to reinstall in existing system)

So we can have a new job: satellite6-reinstall or add REINSTALL boolean to the current install job and if true we add satellite-installer --scenario satellite --force ..... and the other needed steps.

omaciel commented 8 years ago

It would be great if all other tasks involved in the installation (eg. creating repo files, enable/disabling repos, firewall rules, etc) could be smart enough so that re-installing could avoid repeating some steps if things have already been done or do them so that you don't end up with multiple artifacts.

omaciel commented 8 years ago

Maybe we already do all these things? 😃

elyezer commented 8 years ago

Considering the fact that we are looking for a smart tool, and things should be done only if they are not applied I would recommend porting everything to ansible. It already have the "do if needed" feature by default.

Not all tasks check for things being present and a great refactor will be needed if we decided to do that for the fabric tasks.

kbidarkar commented 8 years ago

@omaciel, @elyezer, we need to decide on this quickly, I mean move to ansible and if we decide to then we need to start it qucikly. :)

I say so because I need to add multiple features to our setup.

elyezer commented 8 years ago

@kbidarkar I think is better to you make the call. What do you think?

My opinion is that doing in ansible is more reasonable because in addition to what I've mentioned above, we can leverage ansible features and make, for example, satellite6-installer install satellite on 1 or more machines on the same job for example.

On the other hand, porting the entire automation-tools will require time and maybe is best to start that in parallel or do some focused effort.

rochacbruno commented 8 years ago

The migration can be gradual, we can call fabric tasks from ansible and then, migrate one by one to pure ansible task.