- occi-wg - lists.ogf.org

OCCI'fied Amazon EC2
by Edmonds, AndrewX 23 Mar '12

23 Mar '12

http://occi-wg.org/2012/03/21/occi-fied-amazon-ec2/ ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

Screencast showing an EC2 backend for OCCI
by Feldhaus, Florian 23 Mar '12

23 Mar '12

Hi all, Max Günther, a student of me, has developed a EC2 backend for rOCCI. The result looks very promising. He made a screencast showing the current functionality: http://vimeo.com/38509679 The code is already in the repository, but will undergo some more testing until the next release: http://dev.opennebula.org/projects/ogf-occi/repository https://github.com/ffeldhaus/rOCCI (Mirror) Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

4 3

OCCI Session Notes from OGF34
by Edmonds, AndrewX 20 Mar '12

20 Mar '12

These will be placed on the OGF site when possible. Thanks to Alex! OGF34, Oxford, United Kingdom Wed, Mar 14 2012, 15:30 BST Session Leader: Thijs Metsch Note Taker: Alexander Papaspyrou Michael Behrens (PaaS, <insert link to preso here>): * spec for PaaS wanted that outlines architecture components * within OCCI: make inventory of PaaS, use case-based approach, requirements * also: contact providers (CloudFoundry, OpenShift) * extend J2EE model to multiple providers of building blocks regarding service delivery * important: design for mobile devices! * re OCCI: should provide the interfacing to the big players * The data layer in PaaS should be location transparent * Need to clear out what the elements in PaaS mean * define the platform first: what are the components, and how do they relate to the infrastructure * platform can be considered as means to provide * every PaaS is different, needing its own description * even application components are somewhat differing from each other * start with extensions like node, key value store: simple things * what about a registry? * does the DRMAA approach fit into the PaaS model * CompatibleOne concept: OCCI usage on multiple levels, in the sense of a SOA * take a look at service management * in fact, everything is there in OCCI * means for describing services * as a resource * in a standardised way * main question is: how to describe the service collection? * what about intercloud? * brokerage services * big data access / movement * service registry profile for certain domains * take a look at telco platforms * make a directory of common categories James Marshal from CompatibleOne volunteers to help with inventory -- Interlude -- Connect to Inder * necessary to discuss and evaluate networking problems * setup network-specific meeting at next OGF / plugfest with NSI ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

German Government Recognises OCCI as Leading the Cloud Standards Arena
by Edmonds, AndrewX 19 Mar '12

19 Mar '12

In case you haven't seen it... http://occi-wg.org/2012/03/18/german-government-recognises-occi-as-leading-… Andy ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

Happy St. Patrick's Day!
by Edmonds, AndrewX 16 Mar '12

16 Mar '12

http://occi-wg.org/2012/03/16/happy-st-patricks-day/ PS: Lots of new posts up on the blog and more to come! ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

Updates to OCCI core
by Feldhaus, Florian 14 Mar '12

14 Mar '12

Here are some ideas for extending the description of attributes. To more clearly specify attributes, a new new class 'attribute' should be added to OCCI Core. For the class diagram this would require to remove '+ attributes :Set<String>' from category and instead connect it with the attribute class in a many to one dependency. Ideas for the attribute class: - the attribute class should consist of the attributes: mutable, required, type, default - the naming of attributes of the OCCI specification MUST start with occi followed by term and the attribute name (e.g. occi.compute.cores) - the naming of attributes of user defined mixins MUST start with the reversed domain name of the mixin scheme followed by the term and the attribute name (e.g. com.example.my_mixin.my_attribute) - the attribute type should contain restrictions on the attribute like for example: * string: choices, min_length, max_length * number: bounds (one or more lower and upper bounds) - there might be more detailed attribute types such as URL or URI, float, integer, ... --Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

4 4

OGF34 OCCI Sessions
by Edmonds, AndrewX 14 Mar '12

14 Mar '12

Hi all, We're having significant networking issues here in Oxford so we cannot host a skype confcall. Apologies. Andy ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

OCCI Extensions, NIST and others
by Edmonds, AndrewX 12 Mar '12

12 Mar '12

Hey all, At the SNIA Cloud Plugfest Florian and I went through a number of required extensions that are needed for closer compliance with the NIST cloud computing VM use cases. I've documented them here [1]. Also included in the document is the beginnings of OVF capabilities and updates to CDMI interoperability. Comments etc gladly welcome. Also we can talk about these and others at the Weds. sessions at OGF34. Andy [1] https://docs.google.com/document/d/1XnUssN8nYUAwvuuI-3WGmbtIR-O33RS0gF9ZFed… ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 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.

1 0

Summary of the JSON rendering discussion
by Feldhaus, Florian 12 Mar '12

12 Mar '12

Following I try to summarize the recent discussion of the JSON rendering, please feel free to add, extend or correct it: - different content types * different content types make it easier to identify the content of the message * content type negotiation may get more complicated * for GET requests, the client may know what type of content he's requesting (even though he may use different content types in Accept and doesn't know which one the server responds with) * for POST requests, the server doesn't know what content type he gets - if just application/json is used as media type (instead of e.g. application/occi+json or more detailed content types), the client doesn't know which semantics the content have - CDMI uses specific media types to help client and server to know the semantics of the content without first interpreting the content - how should the location of the entities be named? location, href, uri? - there should be a recommendation that the JSON format should be rendered compact (e.g. without unnecessary whitespaces) in production use - how should the category identifier be called? rel, type? rel is based on the HTTP way of doing things - make the JSON format as easy to use and as compact as possible - there was a security issue with having JSON arrays at the top level. This issue is solved as of ECMAScript5 [1]. Using just an array with all categories or entities would be a compact rendering. Questions are: -- Is ECMAScript5 already widely adopted? -- when exactly does this security issue appear? Can it be exploited for HTTPS connections where the OCCI endpoint has been clearly identified by a valid certificate? - should there be a JSON rendering of Locations or is it sufficient to have text/uri-list? Could a JavaScript implementation easily parse text/uri-list if the client intends to just get the locations of some object (maybe together with a filter)? - rendering of entities: -- is rel necessary for actions? -- which fields are really necessary for links inside of entities? --- smallest version would be just the link location --- title would be very handy for displaying in user interfaces --- title, target uri/href, rel, link href/uri, link rel and attributes would make it easier for the client to directly use links, but may introduce a lot overhead for huge number of links -- attributes should be rendered according to their hierarchy (e.g. as { 'occi': { 'core': { 'id': '123' } } } ). This makes using attributes very simple for clients, especially those written in JavaScript. -- all attributes must be unique regardless how they are rendered. This should be taken care of in OCCI Core and may be achieved by using reversed domain names for user/provider defined mixins. -- depending on the impact of the security issue with Top Level arrays, entities can be rendered either compact with only an array or a little more verbose by using a JSON object/hash with key 'entities' and the array of entities as value -- should single entities be rendered differently from multiple entities? e.g. should a single entity be directly rendered as JSON object/hash with kind, mixins, … or should it be in the same format as multiple entities e.g. inside an array? - rendering of categories: -- should attributes be rendered as single string or as hierarchy of hashes (e.g. "occi.core.id" : ... vs. "occi": { "core: { "id": … } } }? -- type should be extended with the restrictions defined in OCCI Core for the attribute type. This can be e.g. for string: choices / min_length, max_length and for numbers: bounds Example of proposed compact rendering (save whitespaces) of OCCI entities by Jamie, Florian and others: http://pastebin.com/aun0Ha2D Combination of above rendering with Ralfs Collection format (replacing 'collection' to 'entity' because I don't like using the name collections when its an array of entities ;-) ): http://pastebin.com/bffFtL19 Example of proposed category rendering by Ralf, extended by Jamie, Florian and others: http://pastebin.com/txhnt7uX [1] http://flask.pocoo.org/docs/security/#json-security --Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

1 0

Updates to OCCI specification
by Feldhaus, Florian 12 Mar '12

12 Mar '12

Hi, picking up the recent discussion on JSON, I'd like to summarize the current ideas as far as I understood them from the recent discussion. First, there was the proposal to put the changes in the right documents as errata. I very much second this, even if we may face problems pushing it through OGF as errata. Thus I'd like to split the ideas into the corresponding parts of the OCCI and send separate mails for them. It would be nice if we could keep the threads separate. These are currently ideas and I might have missed some of them. Please add all ideas I missed and try to focus on getting everything ready for integration into the specification as soon as possible. There are several implementations ready to pick up especially the JSON rendering. Also it would be great if we could get OCCI from proposed recommendation to full recommendation as soon as possible. Cheers, Florian ------------------------------------------------------------------------------- GWDG - Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077 Göttingen Fon: 0551 39-20364 Fax: 0551 201-2150 E-Mail: florian.feldhaus(a)gwdg.de WWW: www.gwdg.de ----------------------------------------------------------------------------------- Geschäftsführer: Prof. Dr. Ramin Yahyapour Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -----------------------------------------------------------------------------------

3 2