[occi-wg] erocci
Jean Parpaillon
jean.parpaillon at free.fr
Fri Jan 24 09:45:28 EST 2014
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 at 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 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
>
>
>
>
>
> --
> 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
-------------- next part --------------
{
"kinds": [
{
"term": "compute",
"scheme": "http://schemas.ogf.org/occi/infrastructure",
"title": "ThisPC",
"attributes": {
"occi": {
"compute": {
"architecture": "x86",
"cores": 1,
"hostname": "pc001",
"memory": 5,
"speed": 4000,
"state": "inactive"
}
}
}
}
]
}
More information about the occi-wg
mailing list