[occi-wg] erocci
Augusto Ciuffoletti
augusto at di.unipi.it
Fri Jan 24 05:48:56 EST 2014
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). Then I tried to test
POSTing the attached file with the following cmd:
curl -X POST -d at compute.json -H 'content-type: application/occi+json' -v
http://localhost:8080/compute/
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140124/d559e7d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compute.json
Type: application/json
Size: 463 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140124/d559e7d8/attachment-0001.bin>
More information about the occi-wg
mailing list