-
Notifications
You must be signed in to change notification settings - Fork 302
Redeploy unit in place #760
Comments
@jcderr How do we handle changes in |
I would say to re-evaluate it. If required, go ahead and reschedule it to another machine, but prefer to stay on the same machine if necessary. |
I think we can distill this down to a scheduling optimization. When the engine reconciler runs, it needs to identify when the contents of a given unit have changed and prefer the currently-scheduled host (if one exists). |
I would love to see reload, or even just restart features of systemctl make their way up into fleetctl. In my case, I would use it for reloading a docker image from the repository in place similar to the following example unit:
This particular unit is kind of awkward because there are so many repeated commands, but the way this works is if you call I'm new to this whole thing, so I might be missing something obvious too. Thanks for the great work on coreos to everyone involved. |
Starts and stops a unit in one command. refs coreos#760
Starts and stops a unit in one command. refs coreos#760
Starts and stops a unit in one command. Adds support to specify SSH port for SSH based commands: * journal * status * ssh * restart refs coreos#760
Starts and stops a unit in one command. Adds support to specify SSH port for SSH based commands: * journal * status * ssh * restart refs coreos#760
Starts and stops a unit in one command. Adds support to specify SSH port for SSH based commands: * journal * status * ssh * restart refs coreos#760
Starts and stops a unit in one command. Adds support to specify SSH port for SSH based commands: * journal * status * ssh * restart refs coreos#760
This should be easy to do now. We could accept a new unit file using something like |
👍 |
which fleet version has the --overwrite option? |
Hi Brian, Is this fix available now? On Fri, May 1, 2015 at 9:48 AM, Brian Waldon [email protected]
|
@vish0007 no code has been written to support this |
+1 |
6 similar comments
+1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+1 @bcwaldon Whats the ETA for this? |
+1 |
1 similar comment
+1 |
+1 And what about a rolling update of |
dup #1295 |
Hi new replace functionality is in this new PR #1509 which needs testing... there are many corner cases... if you guys are still on it. |
@kayrus why have you closed this issue? The PR is not in yet... |
Here's a possible workaround for reloading a service across the fleet. Note that this isn't really tested, so it's more theoretical than anything: # Get the IP address of each host running <name>.service, then ssh into each one
# and reload it using systemctl.
for ADDR in $(fleetctl list-units --no-legend | grep <name>.service | awk '{ print $2 }' | awk --field-separator '/' '{ print $2 }'); do
ssh $ADDR systemctl reload <name>.service
done Another approach: # Same idea, but using machine id instead of IP address. Not sure if it supports
# the same syntax as bare `ssh` for running a command on the server and exiting.
for MACHINE in $(fleetctl list-units --full --no-legend | grep website.service | awk '{ print $2 }' | awk --field-separator '/' '{ print $1 }'); do
fleetctl ssh $MACHINE systemctl reload <name>.service
done |
It would be quite nice to be able to replace an existing unit in one go, if a change must be made, preserving its location.
fleetctl submit some.unit.service
fleetctl run some.unit.service
fleetctl reload some.unit.service
Fleet should replace the unit conf in-place, stop the running unit, and restart it using the new conf.
The text was updated successfully, but these errors were encountered: