Proposal for a spec file that allows for initialization of a volume with pre-seeded contents about openstorage HOT 5 CLOSED

I propose we start with a simple implementation as an additional field to CreateOptions

// CreateOptions are passed in with a CreateRequest
type CreateOptions struct {
    // FailIfExists fail create request if a volume with matching Locator already exists.
    FailIfExists bool
    // CreateFromSnap will create a volume with specified SnapID
    CreateFromSnap VolumeID
       // SourceURI e.g github://github.com/libopenstorage/openstorage
    SourceURI string
}

from openstorage.

That would work for starters. However I think people will have multiple source URIs and do not necessarily want that to equate to multiple production volumes to manage. That said, this is a start in the right direction.

from openstorage.

The need is very practical, But I feel putting provisioning logic in osd/driver code will make it more complex.
I like the way Hashicorp Packer does the provisioning for preparing images. You may like to take look at that.

Parse the yaml file, and move the provisioning code in shell script or if any other supported provisioner format like chef, ansible. (sooner or later, people will raise this request too)

So whole provisioning will be offloaded to external process rather then OSD.

from openstorage.

I think my original proposal is a bit complicated but I think one of the most common practices with volumes and containers are to start up a job with some pre populated data. In order to do that you want to create a volume staged with some contents and that is the motivation behind this PR.

Maybe a simple workflow where a volume create followed by a "cp" of some sort into the volume (not a running container) will suffice. Then the volume can be attached to the container ... and then the container can be started with the volume with the staged contents.

from openstorage.

Seeding for github is supported.

from openstorage.