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)