[occi-wg] erocci
Augusto Ciuffoletti
augusto at di.unipi.it
Mon Jan 20 09:49:44 EST 2014
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140120/a7841a31/attachment-0001.html>
More information about the occi-wg
mailing list