September 2014 - occi-wg

NIST RATax_CloudMetrics < CloudComputing < TWiki
by Sill, Alan 09 Sep '14

09 Sep '14

Thought you would be interested in the following link. Topic: Cloud Metrics Sub Group This is the main page of the RATAX Cloud Metrics sub group. In this page you'll find information related to what to team is currently working on. Link: http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/R… Alan

1 0

RFC2616 is Dead
by Sill, Alan 09 Sep '14

09 Sep '14

(As discussed today in the OCCI first afternoon session.) Topic: Don't use RFC2616. Delete it from your hard drives, bookmarks, and burn (or responsibly recycle) any copies that are printed out. Link: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead Alan

1 0

OGF OCCI sessions starting now...
by Metsch, Thijs 09 Sep '14

09 Sep '14

...if you want to join remotely feel free to ping me via skype... Cheers, -Thijs Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

OCCI SLAs extension
by Katsaros, Gregory 05 Sep '14

05 Sep '14

Hi all, My name is Gregory Katsaros and I am a research scientist working in Intel Labs. Together with my colleagues Thijs Metsch and John Kennedy we have been working on an extension of OCCI for the support of Service Level Agreements. I am sharing with you a draft with our views and ideas. A relevant discussion/presentation will take place also next week in the context of OGF42 OCCI sessions. Your comments and feedback are welcome. Kind regards, Gregory Katsaros -- Intel Corporation, Cloud and Services Lab --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

OCCI session @ OGF42
by Metsch, Thijs 03 Sep '14

03 Sep '14

Hi all, As you can see all 3 OCCI sessions are now scheduled on Tuesday [1]. The first session will start at 9 - we'll use the first 15 minutes as agenda bashing. So please think about what you want to talk about :) Should you be unable to join the first session please drop me a private email with the topic you want to discuss and I'll make sure it'll find a spot. Looking forward seeing you all in London! Cheers, -Thijs [1] http://www.ogf.org/dokuwiki/doku.php/events/ogf-42/schedule Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

3 2

Fwd: Feedback, suggestions and questions from EGI FedCloud
by Boris Parak 02 Sep '14

02 Sep '14

Hello everyone, since OGF42 in London is rapidly approaching, I would like to start a discussion ... to get a running start. The following issues/questions/suggestions are mostly based on our practical experience with OCCI in EGI FedCloud. Feel free to comment (or ignore me) :-) Items are ordered by importance. 1.) OS and resource templates (mixins -> resources) While moving to production in the last few months, we've found that os_tpl and resource_tpl mixins do not provide enough information about the "resources" (images and flavors in OpenStack, virtual machine templates in OpenNebula etc.) they represent. I know that this is a quite common approach adopted for instance by Amazon in AWS EC2 but in some environments we need to be able to "attach" more information to these concepts. In general, the following information is required: os_tpl: external appliance ID resource_tpl: number of cores, amount of memory, amount/type of storage, included optional block devices Term and scheme of a mixin simply do not provide a strong-enough mechanism. At the moment, we have to use external mapping mechanisms (an LDAP-based information system) and therefore duplicate information in several places. It would be very helpful to be able to attach arbitrary attributes to os_tpls and resource_tpls. Perhaps specify them as resources instead of mixins and use linking to attach them to compute instances (inline, on creation)? Do you have any other ideas? 2.) Advanced networking concepts This will be very brief and vague. Do you have any plans to represent various networking elements (routers, switches, gateways, etc.) in the standard? Or, in general, extend the infrastructure network specification to include tools for specifying complex network setups? 3.) Available resources Are there any plans for including concepts and querying mechanisms for getting the amount of currently available resources? Is this outside of the scope of OCCI or the commonly accepted concept of the "cloud"? How would you handle this? Would it fall into OCCI Monitoring? I'm thinking in terms of "How many 'resource_tpl#small' computes can I launch right now?". 4.) Asynchronous/queued actions Is there a recommended approach to asynchronous or queued actions (not necessarily OCCI "actions")? This goes mostly to implementation. Should I block until the action is finished? Can I respond with HTTP 202 Accepted (for example, it doesn't have to be HTTP) and process it later? In that case, shouldn't I provide a link where the user can get the current status of his action? Did anyone deal with a similar problem? Is there a solution you would prefer, standard-wise? 5.) Updating mixins When using a partial update to add/replace a mixin (or mixins) on a compute instance (as an example), how do I know which mixin to replace? Or whether to replace it or add a new one? Shouldn't OCCI specify which mixin types can be included only once per instance? Or define some "replacing" rules? I'm looking at [1], to give you a practical reference. [1] https://wiki.openstack.org/wiki/Occi#Scale_Up_a_VM Any feedback will be greatly appreciated. We can, of course, continue the conversation next week in London. Hope to see you all there. Thanks! Cheers, Boris Parak --- On behalf of EGI FedCloud, CESNET and the rOCCI dev team

4 5