Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Beginnings of a loop provider. #4
Conversation
axw
reviewed
Jan 27, 2015
| + | ||
| + blockDevices := make([]storage.BlockDevice, len(volIds)) | ||
| + for idx, volId := range volIds { | ||
| + device, ok := lvs.volIdToBlockDevice[volId] |
axw
Jan 27, 2015
Collaborator
We can't assume that we'll have created the device in the same session. Doesn't matter for now, since this code isn't called yet.
kat-co
Jan 27, 2015
I've left it this way for now since I'd have to write some code to inspect the loop devices to transform them back into the BlockDevice struct. I'll take care of this later.
axw
reviewed
Jan 27, 2015
| + if err == NoLoopDeviceErr { | ||
| + nextDevNum, err := findAvailableDeviceNumber(lvs.runCmd) | ||
| + if err == nil { | ||
| + createLoopDevice(lvs.runCmd, nextDevNum) |
axw
reviewed
Jan 27, 2015
| +} | ||
| + | ||
| +func providerId(arg storage.VolumeParams) string { | ||
| + uuid, err := utils.NewUUID() |
axw
Jan 27, 2015
Collaborator
This needs to be something we can link back to the loop device. Perhaps just compose it from the machine ID and the loop device name. We'd need to pass the machine ID when creating the provider.
|
Probably good enough for now, but it won't work if the agent bounces. |
kat-co
commented
Jan 27, 2015
|
I think I see a potential issue: I think we want the block file to be correlated with the provider ID so we can re-attach them across restarts. If we include the loop device in the provider ID, this may not make sense over time: e.g. we could run into a situation where we have machine1-loop0, machine1-loop9. |
|
@katco- Good point. In that model refactor that I spoke about in the standup, I've changed the storage provider so that CreateVolume returns a Volume and AttachVolume returns a VolumeAttachment. The former contains information specific to the volume (e.g. size, persistence), whereas the latter contains information specific to the attachment (e.g. the device name). So... have the volume ID encode the machine ID and the name of the file. You can then map that to the device path using |
wallyworld
reviewed
Jan 29, 2015
| storage.RegisterDefaultPool("local", storage.StorageKindBlock, LoopPool) | ||
| } | ||
| + | ||
| +func RunCmdFn() RunCommandFn { |
wallyworld
reviewed
Jan 29, 2015
| + panic(err) | ||
| + } | ||
| + return uuid.String() | ||
| + return fmt.Sprintf("%s-%s", machineId, loopDeviceName) |
|
LGTM for demo purposes once tests pass |
added a commit
that referenced
this pull request
Jan 29, 2015
wallyworld
merged commit ef637d5
into
wallyworld:storage-feature
Jan 29, 2015
pushed a commit
that referenced
this pull request
Sep 9, 2015
pushed a commit
that referenced
this pull request
Oct 19, 2015
pushed a commit
that referenced
this pull request
Oct 22, 2015
pushed a commit
that referenced
this pull request
Mar 23, 2017
kat-co commentedJan 27, 2015