[occi-wg] erocci
Jean Parpaillon
jean.parpaillon at free.fr
Fri Jan 24 08:44:45 EST 2014
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 at 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 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
>
>
>
>
>
> --
> 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