[occi-wg] erocci
Jean Parpaillon
jean.parpaillon at free.fr
Fri Jan 24 05:59:01 EST 2014
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 at 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 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)
--
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
More information about the occi-wg
mailing list