This repository has been archived by the owner on Sep 4, 2021. It is now read-only.
Implement Persistent Volumes #3897
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lmars
force-pushed
the
persistent-volumes-1
branch
2 times, most recently
from
e24e66d
to
0c3914e
Compare
titanous
reviewed
Feb 13, 2017
| register("volume", runVolume, ` | ||
| usage: flynn volume | ||
| flynn volume show [--json] <id> | ||
| flynn volume decommission <id> |
There was a problem hiding this comment.
Should this command be scoped to the app by default?
controller/scheduler/host.go
Outdated
| Type: VolumeEventTypeDestroy, | ||
| } | ||
| } | ||
| ch <- e |
There was a problem hiding this comment.
Should this select on h.stop as well?
| // and this volume doesn't exist on that host | ||
| if job.HostID != "" && vol.HostID != job.HostID { | ||
| continue | ||
| } |
There was a problem hiding this comment.
Is exclusivity enforced in flynn-host too? There can technically be two schedulers scheduling jobs at once under failure conditions.
| @@ -1035,6 +1274,10 @@ func (s *Scheduler) HandleInternalStateRequest(req *InternalStateRequest) { | |||
| req.State.Formations[key.String()] = &f | |||
| } | |||
|
|
|||
| for id, vol := range s.volumes { | |||
| req.State.Volumes[id] = &(*vol) | |||
There was a problem hiding this comment.
What is the reason for &(*vol)?
There was a problem hiding this comment.
We need to copy it to create a "snapshot" of the scheduler's state to pass back to the caller.
lmars
force-pushed
the
persistent-volumes-1
branch
from
5fc5d22
to
e9fedf0
Compare
|
@titanous comments addressed. |
titanous
approved these changes
Mar 7, 2017
lmars
force-pushed
the
persistent-volumes-1
branch
from
e9fedf0
to
db239f9
Compare
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Useful for the scheduler creating volumes which it needs to track. Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
Signed-off-by: Lewis Marshall <lewis@lmars.net>
lmars
force-pushed
the
persistent-volumes-1
branch
from
db239f9
to
d714bca
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is a continuation of the work already done on the persistent-volumes branch to implement persistent volumes as per #2438.
Summary:
volumesandjob_volumestables in the controller databaseVolume.JobID)flynn volume decommission IDwhich causes the volume to not be attached to any new jobsblockedstate waiting for either the host to come back up or the volume to be decommissioned. This then means if a host is rebooted which has data for a process type, the job just stays down until the host comes back rather than being restarted on a different host with an empty volume, but if the host has really gone away then it is up to the operator to decommission the volume and unblock the job to be scheduled on a different hostThings which need to be considered but not included in this PR:
flynn volume backupandflynn volume restoreso that if a host is lost and volumes need to be decommissioned in order to move jobs to other hosts, operators can first restore volumes so that the unblocked job doesn't have to start with a completely empty volume