January 2014 - occi-wg - lists.ogf.org

Intel hiring for SLAs in OCCI
by Kennedy, John M 03 Mar '14

03 Mar '14

Dear all, Just to let you know Intel are looking to hire a researcher/developer to be based in London (White City/Wood Lane) whose primary role will be to develop an extension to OCCI to support SLAs during 2014. All the info here: http://intel.ly/1eocRGg Please forward to any potential candidates you think might be interested. Best wishes, - John. ------------------------------------------------------------- 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 1

Meeting notes
by Metsch, Thijs 03 Feb '14

03 Feb '14

Hi all, First of all thanks to all for (remotely) attending, prepping and adding to the discussions yesterday. tl;dr: * We will start writing an experience document plotting out some clarifications * We plotted out plans for OCCI 1.2 (roadmap for documents) * Minor semantic issues were discussed and resolved to get better interop between implementations. With that said we want to start using our bi-weekly calls to track progress. Meeting notes: * " issues" within current documents o Infra: The usage of storage links vs OS templates for image selection was discussed. Suggestion (as the spec hints but needs to clarified in experience doc) to use template mechanism for image selection o Typing of attributes: Suggestion to keep core clean from types but where necessary define them in the rendering docs. o how to resize -> impl looks after that * Experience document o Suggestion to write experience document - start with a google doc; Implementations which could be covered: ? rOCCI ? pyocci ? erocci ? pySSF ? ??? o Should be written from the PoV of Infrastructure - a ToC has been suggested and has been put in a google doc for sharing later. * OCCI 1.2 - will become 6 docs: o Note: MUST be backwards compatible! o Infra model ? For 1.2 it would be worth thinking on a router mixin for the networking part ? Error state needs to be added ? default method for actions in infrA should be defined. o Platform model ? Should hold a suggestion for supporting PaaS o Core ? pagination ? sub resources ? QI enhancements (default values, hierarchies etc, better queries) o http protocol ? split from current doc o text rendering (text/plain + text/occi -> text/occi+plain etc) ? split from current doc o JSON document ? Will go into public comment asap o Other possible docs/models ? Contextualization ? key management/Security ? Monitoring ? SLA ? Billing ? Interdomain networking ? OCCI-DRMAA * OCCI for OpenStack questions: o We discussed how floating IPs are implemented in the OpenStack OCCI api. o firewalls are OS specific o how to transfer and keep IP address -> change link source o how to supply your own IP address to the VM? * Misc o Website should list specs in draft state too! Please feel free to ping questions and suggestions on where you could contribute and help - I'll ping people with the action items we've assigned to them in parallel :) Again thanks for making OCCI very much alive and kicking - Much appreciated, -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

2 1

XML to describe instances
by Augusto Ciuffoletti 27 Jan '14

27 Jan '14

Time ago someone proposed to use XML as a tool to describe OCCI. As a result we now have the XML description of high order concepts (kinds), and an XSD that binds the way in which such higher order concepts are described. This is certainly a result. But XML might be useful also to describe low order concepts, i.e. resources, which is a different (though tightly related) issue. We have an example today in the "erocci" discussion. The fact of having a clean higher order description based on XML/XSD wired in the engine does not help us in clarifying an otherwise straightforward detail about the way resources are described. This is because the JSON rendering is certainly useful for practical reasons, but there is no XSD for JSON (at least to my knowledge). My idea is that having an XSD also for resources (that describes the syntax for resources, not for kinds) would be beneficial: it can be probably derived from the JSON document, but once defined it can be used to automate the validation of XML resource descriptions, and for all those descriptive languages for which an XML mapping exists (JSON included). Comments? -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

2 2

Re: [occi-wg] erocci
by Augusto Ciuffoletti 24 Jan '14

24 Jan '14

Dear Jean and all, here I share a discussion initiated with Jean in December, regarding the erocci client prototype. The purpose (launched by Jean) is the implementation of a prototype client using the Erlang/OTP framework, which is mainly used in telecom applications and developed by Ericsson. The rationale is that OTP is strongly biased by distributed/concurrent environments, and allows flexible and fast prototyping of cleanly defined solutions. So that it is ideal for demo/testing/proofofconcept etc. In this respect, the fact that it is a somewhat niche product is not relevant. Jean has already implemented part of the client, and during the last weeks I browsed his work: in the last email I was questioning him about a "use case" that could help the definition of the user interface. There are also more technical issues, and my reply follows... 2014/1/19 Jean Parpaillon <jean.parpaillon(a)free.fr> > Hi Augusto, > Sorry for the late answer, but I've been really busy these later days. > As some other people looked interested in my implementation during the > last meeting, I think it worth having this discussion in public. I let > you forward... > > Le vendredi 10 janvier 2014 à 18:25 +0100, Augusto Ciuffoletti a écrit : > > Just scratched the surface but now I start having trivial questions: > > what's the final purpose? Even if it is just a proof of concept, you > > certainly have an idea of what it is for. > > What a good question :) Without kidding, what I understood from other > implementations is they focus on implementing a particular extension > (ie, compute) with different backends and connectors to existing APIs: > OpenNebula, OpenStack, EC2, etc... I think this is the case for rOCCI > and I know it is for C.One. > erocci objective is to provide a really generic implementation of OCCI, > not linked to any particular extension, as to build either pure OCCI > application (using OCCI as unique API) or as API adapter, like for the > others. > > Does it sound clearer ? > Not completely. I would like to understand if this engine ("OCCI implementation" for me is too vague) is on the client side (i.e., embedded in a definite-purpose client), or somewhere in the middle (switch) or on the server side (OCCI adapter). In other words, what is the (meaning of the) input and output. In my understanding the input is an XML file that represents a cloud provision using the occi paradigm. This is a static view, not very useful for the user, but precious for testing/proofofconcept/development. The output should be OCCI (using some or any rendering, even XML), and I understand you are aiming at an XMPP architecture. But it is also possible to have another kind of representation (graphical, db?). If this is the framework, ok, now it is explicit. Otherwise, please... > > > > > > My impression is that it is part of the cloud manager, in charge of > > accepting cloud provisioning requests (in json or xml), and turn them > > into an internal representation (mnesia). Does this match? In that > > case a more significant demo should include a demo xml, and the > > possibility to submit a user defined xml, ideally with a curl. The > > result of the submission might be rendered in some fancy way elsewhere > > (graphic popup). > > > > About the code, there is probably a redundant use of > > "register_extension" that is defined in occi module, but hello prefers > > to use the one defined in occi_category_mgr. > > You're right, I was thinking about making occi module the only > entry-point for the framework, but given the changing internal APIs, it > is not really effective as of today... > > > Nothing relevant. And I noticed that you often use supervisors where a > > worker might be sufficient (unless I missed something). > > This is indeed my first real erlang application. I would be really > interested in knowing in what my use of supervisor is not relevant. > The "nothing relevant" refers to my previous point (about the "register_extension") which is almost mere syntax. My point about the supervisor (instead of a simple worker) is more significant. A supervisor is useful to control a number of child processes: why do you use one if there are none? Maybe you have something in mind that I have not understood, or maybe you use a powerful tool first to refactor to a simpler at a later stage in development. It is just to know... > And also, why d'you use the xml parser included in the exmpp, instead > > of the more stable xmerl? > > My really next step after finishing one complete column of the status > wiki page (means a complete implementation of at least one rendering) is > to implement XMPP transport. That's why I've been integrating exmpp from > the beginning and then use its XML parser which is also known to be > quite performant... but this is not the biggest argument for me. > XMPP is a powerful protocol, the idea in itself is exciting. But with the "restful" paradigm we have opted for a rigorous "plain HTTP" approach. Is XMPP really useful for us? And also: the server on the other side must understand your XMPP? > > > Next step is to explore the category_mgr... > > > > > > Bye! > > > Cheers, > Jean > Bye... Augusto PS: sorry for not (remotely) showing up at OGF: my fault, I probably missed the e.mail with the room link. Any news about the monitoring thing? > > Augusto > > > > > > > > 2014/1/8 Jean Parpaillon <jean.parpaillon(a)free.fr> > > Hi Augusto, > > Thank you very much for your feedback. > > I have updated the README file wrt to your report. > > > > Let me know would you need some clarifications. > > > > > > Cheers > > Jean > > > > Le mercredi 08 janvier 2014 à 12:36 +0100, Augusto Ciuffoletti > > a écrit : > > > Hi Jean, > > > > > > > > > I'm starting today to explore your work, from the > > "start.sh", and > > > proceed incrementally. I have now an idea of how you have > > modularized > > > the whole (the erocci.png). Your suggestion for me (point 3) > > is a > > > reasonable exercise, when I'll have a sufficiently clear > > idea of the > > > whole, so I'll do that if I'll reach a reasonable > > comprehension of the > > > whole. My target is to make monitoring operational, which is > > somewhat > > > straightforward since it is "just" an extension.. > > > > > > ===report=== > > > > > > > > > > > > Not really an issue, but I haven't found the "issues" > > file... > > > > > > > > > Operationally, I checked out erocci and I have tried a > > "make" and a > > > "make all" (not relevant, but there is a "alll" in > > the .PHONY) with an > > > Ubuntu 13.10. On a not completely fresh install I had to > > "apt-get > > > install" the following "dev" packets to have a successful > > make: > > > > > > > > > libexpat1-dev > > > > > > libxml2-dev > > > > > > libssl-dev > > > > > > > > > > > > Next I called the "start.sh" whose final line was: > > > > > > 12:26:40.478 [info] Starting HTTP listener [{port,8080}] > > > > > > > > > ...and finally... > > > > > > curl -v -X GET "http://localhost:8080/-/" > > > * Adding handle: conn: 0x11e7d40 > > > * Adding handle: send: 0 > > > * Adding handle: recv: 0 > > > * Curl_addHandleToPipeline: length: 1 > > > * - Conn 0 (0x11e7d40) send_pipe: 1, recv_pipe: 0 > > > * About to connect() to localhost port 8080 (#0) > > > * Trying 127.0.0.1... > > > * Connected to localhost (127.0.0.1) port 8080 (#0) > > > > GET /-/ HTTP/1.1 > > > > User-Agent: curl/7.32.0 > > > > Host: localhost:8080 > > > > Accept: */* > > > > > > > > > > > > > So, the toy is running, I have to open it :-) > > > > > > > > > Bye! > > > > > > > > > === > > > > /home/augusto/Scrivania/Erlang/erocci/trunk/deps/exmpp/c_src/exmpp_xml_expat.c:17:19: > fatal error: expat.h: File o directory non esistente > > > #include <expat.h> > > > ^ > > > compilation terminated. > > > ERROR: compile failed while > > > > > processing > /home/augusto/Scrivania/Erlang/erocci/trunk/deps/exmpp: > > > rebar_abort > > > make: *** [all] Errore 1 > > > === > > > > > > > > > > > > Bye! > > > > > > > > > Augusto > > > > > > > > > 2014/1/6 Jean Parpaillon <jean.parpaillon(a)free.fr> > > > Hi Augusto, > > > As I told you, I have tried to make some work on > > erocci in > > > order for you > > > to be able to contribute more quickly. > > > > > > 1/ A development status page: > > > > > https://github.com/jeanparpaillon/erocci/wiki/Development-Status > > > Everything is not there. For instance: resource > > creation is ok > > > in JSON > > > (you can have a look at file tests/json/valid7.json > > for > > > instance) but I > > > don't manage yet links nor mixins. > > > 2/ I have open several tickets on: > > > https://github.com/jeanparpaillon/erocci/issues > > > 3/ A useful task for occi wg should be to write a > > little > > > erocci > > > application with a simple config file. Basically, > > the > > > following is > > > needed to have a working OCCI server with erocci: > > > - load one or several OCCI extension files (XML) > > > - map categories to URIs > > > - setup the listener (HTTP, as of today) > > > - setup the backend (mnesia, as of today) > > > This is achieved with erlang code in hello_occi.erl > > file but > > > all this > > > could be described in a configuration file, either > > an erlang > > > configuration file or an XML file. > > > Would you be interested in working on that ? > > > > > > You can already have an example of erlang config > > file looking > > > at > > > start.sh (which generates a config file used by > > hello_occi). > > > You can have an idea on how to use this file by > > looking at > > > http://www.erlang.org/doc/man/config.html > > > > > > This could be a erocci application (like hello_occi) > > to put in > > > examples/ > > > dir. > > > > > > What do you think of it ? Take care: "Diving into > > erlang is a > > > one-way > > > ticket" :) > > > > > http://fr.slideshare.net/pavlobaron/erlang-is-a-one-way > > > > > > Best regards, > > > Jean > > > > > > Le dimanche 29 décembre 2013 à 16:24 +0100, Augusto > > > Ciuffoletti a > > > écrit : > > > > > > > Hi Jean, > > > > > > > > > > > > I'm browsing you erocci: nice work! > > > > > > > > > > > > Curiosity: why XMPP in perspective? Ok, its > > capabilities > > > include plain > > > > HTTP verbs, but isn't it in contrast (i.e., > > redundant) with > > > a RESTful > > > > approach? > > > > > > > > > > > > I'm planning to understand erocci and to include > > the > > > monitoring (which > > > > seems rather straightforward). If I can contribute > > to it in > > > any way, > > > > just let me know: long ago I was familiar with > > Prolog, and > > > Erlang > > > > basics are the same. > > > > > > > > > > > > > > > > Happy new year! > > > > > > > > -- > > > > Augusto Ciuffoletti > > > > Dipartimento di Informatica > > > > Università di Pisa > > > > 56100 - Pisa (Italy) > > > > > > > > > -- > > > Jean Parpaillon > > > Open Source Consultant > > > Phone: +33 6 30 10 92 86 > > > im: jean.parpaillon(a)gmail.com > > > skype: jean.parpaillon > > > linkedin: > > http://www.linkedin.com/in/jeanparpaillon/en > > > > > > > > > > > > > > > > > > -- > > > Augusto Ciuffoletti > > > Dipartimento di Informatica > > > Università di Pisa > > > 56100 - Pisa (Italy) > > > > -- > > Jean Parpaillon > > Open Source Consultant > > Phone: +33 6 30 10 92 86 > > im: jean.parpaillon(a)gmail.com > > skype: jean.parpaillon > > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > > > > > > > > > > > -- > > Augusto Ciuffoletti > > Dipartimento di Informatica > > Università di Pisa > > 56100 - Pisa (Italy) > > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 > im: jean.parpaillon(a)gmail.com > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

3 11

No call today...
by Metsch, Thijs 21 Jan '14

21 Jan '14

Hi, Sorry for the late notice - due to contagious viruses/colds etc we will need to cancel today's call. 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

Re: [occi-wg] JSON rendering issue
by Florian Feldhaus 20 Jan '14

20 Jan '14

Hi, as far as I understood this, the issue is to identify if something is describing an attribute or if it is an attribute itself. Consider this attribute definition { "type": { "required": false, "mutable": false } } and this attribute representation { "type": "string“ } How does an implementation of the JSON Rendering identify which is the attribute definition and which is the attribute representation? It’s quite simple. Only Entities (Resource and Link) have attribute representations and Categories (Kind, Mixin, Action) have attribute definitions. Thus the JSON Parser needs to differentiate between attribute definitions in Categories and attribute representations in Entities. The following alternatives have been discussed as part of the OCCI JSON standardization: 1.) Usage of the full attribute name (e.g. {"occi.core.id“:{}} instead of {"occi“:{"core“:{"id“:{}}}} ). As the dot has special meaning in OCCI as a namespace separator, we decided to reflect this in the JSON spec. This also allows the usage of the Dot Notation in languages which support it (e.g. JavaScript). 2.) Use "attribute-property“ in Categories instead of "attribute“ to state clearly that the attribute property is different from the attribute representation in Entities. We decided against this, as Attribute is (or will soon be) defined in the OCCI Core Model to be the „attribute definition“. Using something like "attribute-representation“ in Entities instead of "attributes" was considered to be confusing. Thus we used „attributes“ both for Categories and for Entities and require the implementor to use the context to identify if they are attribute definitions or attribute representations. Cheers Florian Am 18.01.2014 um 17:10 schrieb Boris Parak <xparak(a)mail.muni.cz>: > Hi Jean, > > I don't think this is ambiguous in any way. The definition of string in JSON is: > > A string is a sequence of zero or more Unicode characters, wrapped in > double quotes, using backslash escapes. [http://www.json.org/] > > Hence: > > { "default": > { "type": "string" } > } > > is "default.type" with value 'string' > > and > > { "default": > "{ \"type\": \"string\" }" > } > > is "default" with value '{ "type": "string" }' > > Or am I missing something? > > Cheers, Boris > > On Sat, Jan 18, 2014 at 2:40 PM, Jean Parpaillon > <jean.parpaillon(a)free.fr> wrote: >> Hi, >> I've spent some hours implementing the rendering of resources attributes >> as defined in JSON spec and, finally, I think it can _not_ be done that >> way because its ambiguous. >> Let me give an example: >> let the following json document: >> { "attributes": >> { "com": >> { "example": >> { "default": >> { "type": "string" } >> } >> } >> } >> } >> >> Parsing this document, one can not say if this defines: >> - an attribute "com.example" with default value '{ "type": "string" }' >> - an attribute "com.example.default" with type "string" >> >> Given the interest of the community in JSON rendering and their >> implementations, I think we should quickly solve this issue and agree on >> a right syntax. >> >> Cheers, >> -- >> Jean Parpaillon >> Open Source Consultant >> Phone: +33 6 30 10 92 86 >> im: jean.parpaillon(a)gmail.com >> skype: jean.parpaillon >> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/occi-wg > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/occi-wg

2 2

JSON rendering issue
by Jean Parpaillon 20 Jan '14

20 Jan '14

Hi, I've spent some hours implementing the rendering of resources attributes as defined in JSON spec and, finally, I think it can _not_ be done that way because its ambiguous. Let me give an example: let the following json document: { "attributes": { "com": { "example": { "default": { "type": "string" } } } } } Parsing this document, one can not say if this defines: - an attribute "com.example" with default value '{ "type": "string" }' - an attribute "com.example.default" with type "string" Given the interest of the community in JSON rendering and their implementations, I think we should quickly solve this issue and agree on a right syntax. Cheers, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

2 2

Re: [occi-wg] JSON collection rendering
by Florian Feldhaus 19 Jan '14

19 Jan '14

Hi, I’d like to give some comments to the issues raised in this thread. 1.) OCCI Collections I agree that there is some confusion around OCCI Collections and it would be good if we (the OCCI WG) would review the definition of OCCI Collections defined in OCCI Core. There it is stated, that "One or more resource instances associated with the same Kind or Mixin instance, automatically form a collection.“ For some implementations (e.g. in the rOCCI implementation of OCCI), OCCI Collections are interpreted as collections of OCCI instances (e.g. OCCI Kind instances, OCCI Mixin instances, OCCI Action instances, OCCI Resource instances, OCCI Link instances). OCCI Collections according to OCCI Core are in my understanding limited to only the OCCI Resource instances of the same OCCI Kind. I would prefer to broaden the definition in OCCI Core to reflect the interpretation of rOCCI, but I’m totally biased. What are your opinions about OCCI Collections? 2.) Full Rendering vs. Listing in OCCI JSON Rendering Let’s first be clear about the use case. I see the following use cases: A.) Render detailed information about one or more OCCI instances for create, read and update operations B.) Render a list of unique identifiers for add (e.g. to mixing), read, update and delete operations Regarding A.) I think the OCCI JSON Rendering document is complete, but may state more specific how collections are rendered (e.g. kinds, mixins and actions returned by the discovery interface). Regarding B.) this leads again to the discussion of unique identifiers and locations. For OCCI Kinds, OCCI Mixins and OCCI Actions, the unique identifier ist scheme+term (e.g. http://schemas.ogf.org/occi/infrastructure#compute) For OCCI Entities the unique identifiers is the id attribute (defined as being a URI). The text/uri-list is a good and compact way to render the id attribute. I don’t see any benefit of rendering only the id attributes in JSON. The only question is, if only the id attribute or the absolute / relative location of the resource should be rendered. IMHO this is not yet clear in the HTTP Rendering document. I do see a benefit of including pagination and better querying in the new OCCI HTTP Transport document to reduce the load on the server. In my opinion the split of the Text rendering and the HTTP Transport should have high priority in the next time. I’m willing to contribute, but need someone to push me. The first draft can be found here: http://redmine.ogf.org/projects/occi-wg/repository/revisions/protocol-data-… 3.) OCCI JSON Rendering Review Please review the OCCI JSON Rendering document and add your comments in Redmine http://redmine.ogf.org/projects/editor-pubcom/boards/19 If you have problems using Redmine, please send a mail to the OCCI WG mailinglist so that we can solve your Redmine problems and receive your comments on the document. Cheers Florian Am 18.01.2014 um 18:46 schrieb Jean Parpaillon <jean.parpaillon(a)free.fr>: > Hi Boris, > [ id1, id2, id3 ] > > +1 :) > Jean > > Le samedi 18 janvier 2014 à 17:42 +0100, Boris Parak a écrit : >> Hi Jean, >> >> yep, you are right. The plain rendering has this: >> >> ||> It is RECOMMENDED to use the text/uri-list Accept HTTP header for >> this request. >> >> but it's just a recommendation and the use of 'X-OCCI-Location' or >> 'Location' makes it self-contained without the use of text/uri-list. >> >> So, we should probably do something similar for JSON as well. Both >> >>> { entities: [ id1, id2 ] } (1) >>> or >>> { collection: [ id1, id2 ] } (2) >> >> are acceptable. What about something even less complicated? >> >> [ id1, id2, id3 ] >> >> It's a valid JSON + no other message in OCCI JSON rendering contains >> an array directly + it basically the same as using Location or >> text/uri-list. Of course, IDs would actually be URIs (== locations). >> >> Cheers, Boris >> >> On Fri, Jan 17, 2014 at 1:08 PM, Jean Parpaillon >> <jean.parpaillon(a)free.fr> wrote: >>> Hi, >>> IMO, each rendering should be self-contained, so my answer is yes :) >>> >>> Jean >>> >>> Le vendredi 17 janvier 2014 à 13:05 +0100, Boris Parak a écrit : >>>> On Fri, Jan 17, 2014 at 11:21 AM, Jean Parpaillon >>>> <jean.parpaillon(a)free.fr> wrote: >>>>> If I understand correctly, a collection does not contain the detailed >>>>> representation of resources, only their id, which can have huge >>>>> consequences on implementation performances. >>>>> That's why I was looking for a representation of a list of resources (or >>>>> links) ids. >>>> >>>> That's a good point. At the moment, we are rendering either "full" >>>> collections in JSON or using 'text/uri-list' in the request to get a >>>> list of IDs. >>>> >>>>> Basically, it may be: >>>>> { entities: [ id1, id2 ] } (1) >>>>> or >>>>> { collection: [ id1, id2 ] } (2) >>>>> or >>>>> { >>>>> resources: [ id1, id2 ], >>>>> links: [ id3, id4 ] >>>>> } (3) >>>>> or >>>>> { >>>>> resources: [ { id: id1 }, { id: id2 } ], >>>>> links: [ { id: id3 }, { id: id4 } ] >>>>> } (4) >>>>> >>>>> Any of these is fine for me, but I really think we should agree on a >>>>> representation of collection without resources details. Order is my >>>>> preference order. >>>> >>>> You are right, it might be a good idea to address this in the >>>> document. Do we need a JSON-specific rendering for a collection of IDs >>>> when there is text/uri-list? >>>> >>>>> Any idea on this ? >>>>> Jean >>>> >>>> Boris >>>> >>>>> >>>>> Le vendredi 17 janvier 2014 à 11:11 +0100, Boris Parak a écrit : >>>>>> Yes :) >>>>>> >>>>>> { >>>>>> resources : [ >>>>>> RESOURCE1_JSON_HERE, >>>>>> RESOURCE2_JSON_HERE, >>>>>> RESOURCE3_JSON_HERE >>>>>> ] >>>>>> } >>>>>> >>>>>> where RESOURCE*_JSON_HERE might look something like this: >>>>>> >>>>>> { >>>>>> "kind": "http://schemas.ogf.org/occi/infrastructure#compute", >>>>>> "mixins": [ >>>>>> "http://www.example.org/occi/my_scheme#my_term" >>>>>> ], >>>>>> "attributes": { >>>>>> "occi": { >>>>>> "core": { >>>>>> "id": "1f975fd3-71f7-43e2-bffd-9fdee3825b55", >>>>>> "title": "Cmpt1" >>>>>> } >>>>>> } >>>>>> }, >>>>>> "id": "1f975fd3-71f7-43e2-bffd-9fdee3825b55", >>>>>> "links": [ >>>>>> "/link/storagelink/b2d46a50-ad9f-415a-ac0c-ae7cfed9533c", >>>>>> "/link/networkinterface/66195ffb-5162-4c14-aaf3-426c5aafc1ae" >>>>>> ] >>>>>> } >>>>>> >>>>>> Cheers, Boris >>>>>> >>>>>> On Fri, Jan 17, 2014 at 9:41 AM, Jean Parpaillon >>>>>> <jean.parpaillon(a)free.fr> wrote: >>>>>>> Hi Boris, >>>>>>> May I understand it implies the 2nd approach ? :) >>>>>>> >>>>>>> { resources: { id: ... >>>>>>> >>>>>>> Cheers >>>>>>> Jean >>>>>>> >>>>>>> Le jeudi 16 janvier 2014 à 22:42 +0100, Boris Parak a écrit : >>>>>>>> Hi Jean, >>>>>>>> >>>>>>>> rOCCI is built on top of the JSON spec and we are using the latter. At >>>>>>>> least for me, the document implies this approach, although it's not >>>>>>>> explicitly mentioned there. >>>>>>>> >>>>>>>> Cheers, Boris >>>>>>>> >>>>>>>> On Thu, Jan 16, 2014 at 3:02 PM, Jean Parpaillon >>>>>>>> <jean.parpaillon(a)free.fr> wrote: >>>>>>>>> Hi all, >>>>>>>>> I have found no description of collection rendering in JSON draft. >>>>>>>>> For those who implemented it, how do you achieve it ? >>>>>>>>> >>>>>>>>> If collection is a type on its own, we could have the following >>>>>>>>> notation: >>>>>>>>> { collection : [ id1, id2, id3, ... ]} >>>>>>>>> >>>>>>>>> We can also imagine the following: >>>>>>>>> { resources: [ { id: ...}, { id: ... } ] } >>>>>>>>> or >>>>>>>>> { links: [ { id: ... }, { id: ... }] } >>>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> -- >>>>>>>>> Jean Parpaillon >>>>>>>>> Open Source Consultant >>>>>>>>> Phone: +33 6 30 10 92 86 >>>>>>>>> im: jean.parpaillon(a)gmail.com >>>>>>>>> skype: jean.parpaillon >>>>>>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> occi-wg mailing list >>>>>>>>> occi-wg(a)ogf.org >>>>>>>>> https://www.ogf.org/mailman/listinfo/occi-wg >>>>>>> >>>>>>> -- >>>>>>> Jean Parpaillon >>>>>>> Open Source Consultant >>>>>>> Phone: +33 6 30 10 92 86 >>>>>>> im: jean.parpaillon(a)gmail.com >>>>>>> skype: jean.parpaillon >>>>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >>>>>>> >>>>> >>>>> -- >>>>> Jean Parpaillon >>>>> Open Source Consultant >>>>> Phone: +33 6 30 10 92 86 >>>>> im: jean.parpaillon(a)gmail.com >>>>> skype: jean.parpaillon >>>>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >>>>> >>> >>> -- >>> Jean Parpaillon >>> Open Source Consultant >>> Phone: +33 6 30 10 92 86 >>> im: jean.parpaillon(a)gmail.com >>> skype: jean.parpaillon >>> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >>> > > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 > im: jean.parpaillon(a)gmail.com > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/occi-wg

2 1

JSON collection rendering
by Jean Parpaillon 18 Jan '14

18 Jan '14

Hi all, I have found no description of collection rendering in JSON draft. For those who implemented it, how do you achieve it ? If collection is a type on its own, we could have the following notation: { collection : [ id1, id2, id3, ... ]} We can also imagine the following: { resources: [ { id: ...}, { id: ... } ] } or { links: [ { id: ... }, { id: ... }] } Cheers, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

2 8

Re: [occi-wg] OCCI javascript client
by Florian Feldhaus 17 Jan '14

17 Jan '14

Hi Jean, I just recently started to experiment a bit with AngularJS to refresh my knowledge and write a OCCI factory. Once finished it should be very easy to create OCCI web portals with it. If you like we can share efforts. If you’d prefer a „pure“ JS client, we may also discuss about that. Cheers Florian Am 15.01.2014 um 14:13 schrieb Boris Parak <xparak(a)mail.muni.cz>: > Hi Jean, > > this might be interesting: https://github.com/ffeldhaus/occi.js > > Cheers, Boris > > On Wed, Jan 15, 2014 at 1:13 PM, Jean Parpaillon > <jean.parpaillon(a)free.fr> wrote: >> Hi all, >> I am looking for OCCI javascript clients implementations. >> Are there some people already working on it ? >> The ones I have found on github or else are not maitained since a long >> time. I have began writing one but efforts could be shared. >> >> Regards, >> -- >> Jean Parpaillon >> Open Source Consultant >> Phone: +33 6 30 10 92 86 >> im: jean.parpaillon(a)gmail.com >> skype: jean.parpaillon >> linkedin: http://www.linkedin.com/in/jeanparpaillon/en >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> https://www.ogf.org/mailman/listinfo/occi-wg > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > https://www.ogf.org/mailman/listinfo/occi-wg

5 4