On Thu, Jun 25, 2009 at 4:51 PM, Gary Mazz <garymazzaferro@gmail.com> wrote:
If we move to adding life cycle management to storage, it will open a can of worms. If anything, we should adopt a quality of service metric for storage and let the provider figure out the best way to implement.
Items like capacity management, attaches, disconnects and failure management are OS features out of scope for this spec.
I generally agree (especially about having "what" rather than "how" specifications), but people are going to need to have levers to pull which will largely depend on the implementation. We only need to lock down that which we care about for interop right now (much of which is already handled by CRUD operations). Sam
Sam Johnston wrote:
On Thu, Jun 25, 2009 at 3:45 PM, <shlomo.swidler@gmail.com <mailto: shlomo.swidler@gmail.com>> wrote:
2. Amazon has distinct nouns for "Volumes" and "Snapshots". Amazon's snapshots are not mountable, you can only "copy"/"clone" (not sure which OCCI verb is the correct one here) an Amazon EBS snapshot into a new EBS drive. The OCCI API seems to imply that the result of the verb "image" on a drive yields another drive. So there may be a need to introduce either a new noun "drive snapshot" that is not linkable to any compute noun, or to otherwise differentiate between drives that are mountable and drives that are not mountable.
We plan to expose a basic set of well-defined nouns which implementors are able to use in an interoperable fashion. This will include basic functionality like clone (possibly with parameters like "full" vs "cow") but things like "format", "check", "backup", etc. may or may not be specified.
Note that a "mount" is currently done by creating an association between a compute and a storage resource (specifying the local identifier - eg "sda"). I can't think of a sensible way to advertise "mountability" (short of throwing errors when it fails), and having an "attach" verb on storage devices which accepts a compute device as a parameter feels fugly.
Sam
------------------------------------------------------------------------
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg