[occi-wg] Cloud Audit slides

[Krishna Sankar]

On rare occasions I do agree with Sam ;o) and this happens to be one of
them!

Sam, yep, good thought. CloudAudit can be a capability that works along side
OCCI and CDMI. In fact, the OCCI/CDMI/CloudAudit syndication is easier than
OCCI/CDMI, as in the latter we have to exchange metadata, control path
information as well as figure out the data path.

Cheers
<k/>
P.S : Am surprised that they let you in the datacenter ;o)


On 3/3/10 Wed Mar 3, 10, "Sam Johnston" <samj at samj.net> wrote:

> Thijs/Krishna/OCCI-WG,
> 
> So I haven't said much on the subject yet, beyond highlighting the
> opportunity, but I think it would be sensible for us to list
> CloudAudit (A6) alongside CDMI as a compatible/suggested/recommended
> API. Like CDMI, CloudAudit provides important functionality that is
> just outside of the OCCI charter - rather than bloat OCCI it makes a
> lot more sense for us to align ourselves with other groups.
> 
> Thus far CloudAudit can coexist with OCCI at the same API entry point,
> so it is just a case of advertising its existence to OCCI clients
> and/or suggesting that implementors may want to implement both specs
> together. It does this by using an unusual but standardised directory:
> /.well-known/cloudaudit/ (the .well-known directory was created for
> services like robots.txt so as to avoid polluting the root namespace).
> 
> We have done two things in the current proposals to foster adoption of
> CloudAudit - made the v1 API dead simple (it can thus far be
> implemented with 0 LOC, simply by creating files on a web server) and
> provided an optional resolution service at cloudaudit.net to make it
> immediately useful (you can play in our sandbox at
> http://cloudaudit.net/.well-known/cloudaudit/). It is likely that
> CloudAudit will be useful for OCCI implementors and vice versa - thus
> facilitating the adoption of both APIs.
> 
> You would be surprised how flexible this approach is:
>  - detection is trivial
>  - implementation is fast & costs are negligible (contrast to months
> to get even a simple REST API into production at a large site)
>  - like OCCI we can support any format:
>   - simple boolean primitives (`touch <file>`)
>   - structured formats (xml, json, etc.)
>   - human-friendly formats (PDF printouts or TIFF faxes of auditor
> reports, DOC/ODF originals, etc.)
>  - compatible with other APIs, websites, etc. co-located at the same
> URI (e.g. http://cloud.example.com)
>  - all the usual caching/proxying goodness of HTTP
>  - security (confidentiality, integrity by way of SSL, availability by
> way of DNS)
> 
> Technically the integration would likely be implemented as a <link
> rel="http://cloudaudit.org/" href="http://cloud.example.com"
> title="CloudAudit" /> or similar.
> 
> Anyway for more information or to join visit
> http://www.cloudaudit.org/ (and A6 people can find out more about OCCI
> at http://www.occi-wg.org/)
> 
> Sam (who was in a data center today and thus unable to join the call(s))
> 
> On 3/3/10, Krishna Sankar <ksankar42 at gmail.com> wrote:
>> Thijs,
>>     Good question. I was going to raise this today. This is something which
>> is still not fully defined. We have the concept of a "glue code" which need
>> to be elaborated. Maybe, a call just for the "glue code" might be in order.
>> Cheers
>> <k/>
>> 
>> 
>> On 3/3/10 Wed Mar 3, 10, "Thijs Metsch" <Thijs.Metsch at Sun.COM> wrote:
>> 
>>> 
>>> Thanks!
>>> 
>>> @Sam: can you update us a bit on the CloudAudit/OCCI connection? I'm
>>> almost always unable to attend the CloudAudit calls :-(
>>> 
>>> Thanks,
>>> 
>>> -Thijs
>>> 
>>> On Wed, 2010-03-03 at 08:32 -0700, Mark A. Carlson wrote:
>>>> From the ongoing calls.
>>>> 
>>>> -- mark
>>>> _______________________________________________
>>>> occi-wg mailing list
>>>> occi-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>> 
>> 
>> 
>>