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)

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)

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

On Fri, Jan 24, 2014 at 4:25 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote:

Hi Boris, Ooops, my mistake: I confirm erocci parses resource instance in a "resources" object, not "kinds". On the other hand, in JSON spec draft (version from april 29th 2013), "id" and "title" are not in the "attributes" object, but at the same level as "kind". Has it changed ?

To be honest, I don't have any preference, we just have to agree and let say the first implementation wins :)

I'm actually not sure, Florian should be able to shed some light on this. I seem to remember a private discussion with him about occi.core attributes and how they are not actually that different from other attributes ... I know we decided to include UUID as 'occi.core.id' in attributes and as top-level 'id' to stay compatible. Otherwise, I prefer the all-in-one approach for attributes.

To clarify, in the document I use, the rendering is: { "resources": [ { "kind": "http://schemas.ogf.org/occi/infrastructure#compute", "id": "10c0d368-b096-4923-b21a-a9d026008d05", "title": "ThisPC", "attributes": { "occi": { "compute": { "architecture": "x86", "cores": 1, "hostname": "pc001", "memory": 5, "speed": 4000, "state": "inactive" } } }, "id": "10c0d368-b096-4923-b21a-a9d026008d05" } ] }

Jean

Boris

Le vendredi 24 janvier 2014 à 16:18 +0100, Boris Parak a écrit :

...

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

-- 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

Hi, I've fixed (and pushed) the server not responding status 400 when POST'ing invalid document. In attachement, a valid JSON file. Let's try to converge quickly on JSON rendering.... Cheers Jean Le vendredi 24 janvier 2014 à 18:17 +0100, Augusto Ciuffoletti a écrit :

Mmmmh, in fact, this is not what I expect as a resource definition. Looks like sort of a "kind" definition.

2014/1/24 Boris Parak <xparak@mail.muni.cz> On Fri, Jan 24, 2014 at 4:25 PM, Jean Parpaillon <jean.parpaillon@free.fr> wrote: > Hi Boris, > Ooops, my mistake: I confirm erocci parses resource instance in a > "resources" object, not "kinds". > On the other hand, in JSON spec draft (version from april 29th 2013), > "id" and "title" are not in the "attributes" object, but at the same > level as "kind". Has it changed ? > > To be honest, I don't have any preference, we just have to agree and let > say the first implementation wins :)

I'm actually not sure, Florian should be able to shed some light on this. I seem to remember a private discussion with him about occi.core attributes and how they are not actually that different from other attributes ... I know we decided to include UUID as 'occi.core.id' in attributes and as top-level 'id' to stay compatible. Otherwise, I prefer the all-in-one approach for attributes.

> To clarify, in the document I use, the rendering is: > { > "resources": [ > { > "kind": "http://schemas.ogf.org/occi/infrastructure#compute", > "id": "10c0d368-b096-4923-b21a-a9d026008d05", > "title": "ThisPC", > "attributes": { > "occi": { > "compute": { > "architecture": "x86", > "cores": 1, > "hostname": "pc001", > "memory": 5, > "speed": 4000, > "state": "inactive" > } > } > }, > "id": "10c0d368-b096-4923-b21a-a9d026008d05" > } > ] > } > > Jean

Boris

> Le vendredi 24 janvier 2014 à 16:18 +0100, Boris Parak a écrit : >> 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 >> > > > -- > 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