stage.0: restart master_minion when running stage on master about deepsea HOT 9 CLOSED

The master_minion is the salt master node, but the name of the salt master might not be the minion name. For me,

salt 'admin.ceph' grains.get master

returns salt. If the master_minion does not match the actual minion name of the master, then salt will complain about no target matching. That's why I added master_minion.sls since there's several reasons that the names might not match.

from deepsea.

@swiftgist right, but that was not my point.
The problem that I faced was: I was running an ssh session to the salt master node, and ran stage.0, which at some point tries to restart the salt master node, and kills my ssh session along with the salt-runner execution.

from deepsea.

oh... sorry, working as intended. Your master updated its kernel and needs to reboot. As far as restarting the stage, that requires the /etc/salt/master.d/reactor.conf to do it automatically. Manually, you have to kick off the stage 0 again. I went with the reactor as the solution to this issue.

from deepsea.

But the reactor.conf present in the "master" branch has all lines commented, can you update the version you are using?

Moreover, even if the reactor starts again stage.0, it does not prevent the user from seeing his ssh connection to close without any notice.
This is the kind of issues that I think that can be better handled with the "frontend" application, by alerting the user that the system requires reboot, and ask for the user to run the deployment again.

from deepsea.

I'm also kind of not sure whether we should always upgrade to the latest kernel, I assume this is something that we should discuss.. what about cases when there is a ptf/ fix released for a particular kernel and a newer kernel isn't what we want in the final product?

from deepsea.

@rfd I left it commented out so that things wouldn't be too "magical". Also, I had been testing and modifying it separately so I didn't want to inflict untested versions. As far as the default, I think we should discuss it.

The issue with a separate frontend application is "where would it run?" Some POCs are combining as many roles as possible. Even with a separate admin host, how do you plan to update its kernel when necessary and not reboot?

@theanalyst I think it's a decent default for us though and should be delegated to SUMA since they have the kernel selection functionality already. In other words, we need to make the update step optional, but I will need to know the workflow for the alternate path. I expect Ceph admins using SUMA will still want some level of automation and not have to visit every node.

from deepsea.

@swiftgist, we cannot avoid the reboot. What we can do is alert the user that the current node, where he is running the deployment, needs to reboot. The frontend application should always run in the salt master node.

from deepsea.

I have been leaving this issue open to add some sort of nice messaging prior to the reboot. We need nice messages elsewhere as well. Undecided on the best approach for Salt.

from deepsea.

With 0.5.2, minions will now issue a wall command prior to the reboot.

from deepsea.