DeepSea
DeepSea copied to clipboard
SUSE
Rescind step for Prometheus/Grafana
Running salt-run state.orch ceph.purge does not remove Prometheus nor Grafana. We should add that. :)
Just to have this "ceph.purge" complete - does it remove everything else on all the servers?
hmm wondering if we should actually do this. We might still want to monitor the cluster when purging/recreating. We could add another step, though I can see the downside of this.
Could you share the manual commands required to get rid of the things on the admin node for this?
I have deployed with milestone6, upgraded the admin to milestone7 and reinstalled the other nodes completely. But I can not reinstall the admin node as this is the source for autoinstall etc.. Now I need to get rid of prometheus etc. before I can re-start the SES deployment using deepSea.. or will DeepSea just re-deploy prometheus or adjust that to the new cluster that I deploy?
The scrape targets should be updated according to your new setup when you run stage 2. I'd actually be interested in how that goes. If you don't want to mess around you can simply zypper rm golang-github-prometheus-prometheus grafana on the admin node. After stage 2 everything should be back up.
The more I think about this the less I like the idea to remove grafana/prometheus in purge. If a user intends to re-deploy they will want to monitor. How about I add its own purge orchestration? In this case a user had to explicitly run something like
salt-run state.orch ceph.monitoring.purge
if the monitoring parts should be removed.
From my point of view there is only one reason for the ceph.purge at all - and that is in case there are any strange errors during the first and initial deployment. So why not delete the monitoring things on the admin node in this case, too?
@jan--f Could we continue to have a single command that purges everything? No problem to break it down and document it, i.e. something like: "The purge.everything command purges everything deployed by DeepSea. It consists of the following subcommands, which can be run individually if a full purge is not desired: foo, bar, baz"
The full purge is handy for integration testing. For example, if someone wanted to run the scripts in qa/suites in a loop (on the same hardware), they would need a purge step in between each script.
