<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>
<div style="word-wrap: break-word; ">
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</span></div>
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; ">OK - so it sounds like volumes are going to be in the core API (?) - good. Let's get that into the API spec. It also sounds like
extensions (swift / glance?) are not going to be in the same API long-term. So why do we have the extensions mechanism?</span></div>
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</span></div>
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; ">Until we have an implemented use case (i.e. a patch) that uses the extensions element, I don't see how we can spec it out or approve
it. So if you want it in v1.1, we better find a team that wants to use it and write code. If there is such a patch, I stand corrected and let's get it reviewed and merged.</span></div>
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; "><br>
</span></div>
<div style="color: rgb(0, 0, 0); "><span class="Apple-style-span" style="font-family: Calibri, sans-serif; font-size: 14px; ">I would actually expect that the majority of the use cases that we want in the API but don't _want_ to go through core would be more
simply addressed by well-known metadata (e.g. RAID-5, multi-continent replication, HPC, HIPAA).</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I'm don't agree that the lack of a coded patch means we can't discuss an extension mechanism. But, if you want a specific use case, we have at least one we intend to deliver. It may be more of a one-off than a general case because it is required to give
us a reasonable transition path from our current codebase to Nova. But, it is not an imagined need.</div>
<div><br>
</div>
<div>In the Rackspace Cloud Servers 1.0 API, we support a concept of backup schedules with a series of API calls to manage them. In drafting the OpenStack compute API, this was something that didn't feel generally applicable or useful in the core API. So, you
don't see it as part of the CORE API spec. That said, for transition purposes, we will need a way to provide this capability to our customers when we move to Nova. Our current plan is to do this using the extension mechanism in the proposed API.</div>
</div>
<div><br>
</div>
<div>If there is a better way to handle this need, then let's discuss further. But, I didn't want the lack of a specific example to squash the idea of extensions.</div>
<div><br>
</div>
<div>Troy Toman</div>
<br>
<PRE>
Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE></body>
</html>