Hello Jean, Augusto, may I join your debate? :-) A compute instance should be rendered as a resource not a kind, e.g. { "resources": [ { "kind": "http://schemas.ogf.org/occi/infrastructure#compute", "attributes": { "occi": { "core": { "id": "10c0d368-b096-4923-b21a-a9d026008d05", "title": "ThisPC" }, "compute": { "architecture": "x86", "cores": 1, "hostname": "pc001", "memory": 5, "speed": 4000, "state": "inactive" } } }, "id": "10c0d368-b096-4923-b21a-a9d026008d05" } ] } (or in the attachment)
My implementation is: - both POST'ing and PUT'ing resources do not need id - POST generates a uuid which is returned, prepending the category path. For instance: POST /compute/ -> /compute/xxxxxxxxx - PUT, of course, does not need an id as it is the full path of the url.
We are taking the same approach in rOCCI. Cheers, Boris On Fri, Jan 24, 2014 at 3:45 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:
Hi Augusto, There is a bug from erocci... and an error in your json file :)
The JSON file not being correct, a 400 error should be returned instead of 500. This is the bug.
From the JSON file, there is a missing comma ',' after occi.core.title value. Plus, after discussing on the maillist about JSON rendering, I've implemented the JSON format as described in the spec (while I was using the JSON format from C.One project which is different :/). I'm sorry for that, but this is the price of using a draft representation :P
Hence, the correct JSON file should be as attached. I removed "id" from the attributes but I think the specification is not clear: when POST'ing a resource, should the id be specified, then: - if the id is specified and the resource exists, what should be the answer, - if the id is not specified, what is the server's behaviour ?
My implementation is: - both POST'ing and PUT'ing resources do not need id - POST generates a uuid which is returned, prepending the category path. For instance: POST /compute/ -> /compute/xxxxxxxxx - PUT, of course, does not need an id as it is the full path of the url.
Cheers, Jean
Le vendredi 24 janvier 2014 à 15:21 +0100, Augusto Ciuffoletti a écrit :
2014/1/24 Jean Parpaillon <jean.parpaillon@free.fr> Could you send me the json file you've tried to post ?
Looks like a bug as an bad input file should generate a clear parse_error.
Jean
Le vendredi 24 janvier 2014 à 12:22 +0100, Augusto Ciuffoletti a écrit : > I would like to be already at the step of POSTing a sensor, but what I > have done till now has been simply to upload the monitoring XSD in the > mnesia db, and see that it was there: too easy! And even easier now > as you tell me. > > But then I went back to understand the basics, so I tried to POST the > barebones "compute" I told you about. This was simply to understand > the processing, not to "debug" your code, and this has nothing to do > with monitoring. The problem I observed is related to the last > revision (checkedout circa one hour ago), and the reason why I ask you > is that I'd like to understand: probably I've missed something and > maybe you can help me... > > > > 2014/1/24 Jean Parpaillon <jean.parpaillon@free.fr> > Hi Augusto, > The code is changing really quickly. I suggest first you get > the latest > code. If you have a look at: > https://github.com/jeanparpaillon/erocci/wiki/Development-Status > you will see that links are (mostly) not handled yet (which > can be a big > problem for monitoring). > More inside: > > Le vendredi 24 janvier 2014 à 11:48 +0100, Augusto Ciuffoletti > a écrit : > > I've almost finished descending the code, and I have > successfully > > integrated the monitoring xsd (easy, but hello.erl code must > be > > retouched: loading an extension shouldn't need code > changes). > > > You're right. There has been a step forward in that direction > as > configuration is now given as a single structure to a > occi_config > module. This structure could be loaded direcly with > file:consult/1 > > > Then I tried to test POSTing the attached file with the > following cmd: > > > > curl -X POST -d@compute.json -H 'content-type: > application/occi+json' > > -v http://localhost:8080/compute/ > > > > > Ok. I suppose: > - either you declare links (which is not working yet :/) > - or you should pull the most recent code, as > > I will try to reproduce by the end of the day. > > Keep me informed, > Cheers, > Jean > > > > > > But the reply is a 500 (internal server error) and the > (partial) log > > is > > > > > > Error in process <0.264.0> with exit value: > > > {[{reason,undef},{mfa,{occi_http_collection,from_json,2}},{stacktrace,[{occi_parser,send_event,[{token,objBegin,undefined,1},ok,{parser,undefined,occi_scanner_json,{parser,<0.266.0>,occi_parser_json0,{parser,<0.265.0>,occi_parser_json... > > > > > > By the way, the GET /-/ works ok. Apparently the prototype > should be > > ready to accept the request. Any help? > > > > > > > > 2014/1/20 Augusto Ciuffoletti <augusto@di.unipi.it> > > 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@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@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@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@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@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@gmail.com > > skype: jean.parpaillon > > linkedin: > http://www.linkedin.com/in/jeanparpaillon/en > > > > > > > > > > > > -- > > Augusto Ciuffoletti > > Dipartimento di Informatica > > Università di Pisa > > 56100 - Pisa (Italy) > > > > > > > > -- > > 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@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@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@gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg