sclorg
`make test-openshift` shouldn't configure contributor's box
.. and simply expect that OpenShift is installed on the box, or fail (a bit related to #40).
It would be really suspicious to require our end-users/contributors to run the openshift test-scripts "locally" ATM, since the tasks require root account. We could have some script for user's convenience (doing the oc installation), but the images in CI should be as much prepared as possible, same as user's boxes -- and we should only provide the login info into the openshift instance.
We could have some script for user's convenience (doing the oc installation), but the images in CI should be as much prepared as possible, same as user's boxes -- and we should only provide the login info into the openshift instance.
Isn't this the current state? There is a separate function ct_os_install_in_centos that installs the rpms needed for Centos but does not have to be invoked in the test suite.
Aha, ct_os_install_in_centos is not in postgresql-container#209 anymore - good; but there's still ct_os_cluster_up, which doesn't seem to be safe (root-only stuff).
This is what I was missing:
ct_os_cluster_running && echo "Cluster already running. Nothing is done." && return 0
So it is not that bad - but still, going forward if the cluster is down (that's the case for most contributors ATM, I guess), does it make sense to even attempt to disable firewall etc. when I'm rarely run the build under non-root user? And if user accidentally runs this under root, it changes his system config..
So it is not that bad - but still, going forward if the cluster is down (that's the case for most contributors ATM, I guess), does it make sense to even attempt to disable firewall etc. when I'm rarely run the build under non-root user? And if user accidentally runs this under root, it changes his system config..
Ah right, that is true. So a better way to do this would be to expect an already prepared cluster along with some information to access it. And fail if neither of these is provided.
Might be worthwhile to change the issue name to something more appropriate to the problem at hand.
