Hi,
I've fixed (and pushed) the server not responding status 400 when
POST'ing invalid document.
In attachement, a valid JSON file. Let's try to converge quickly on JSON
rendering....
Cheers
Jean
Le vendredi 24 janvier 2014 à 18:17 +0100, Augusto Ciuffoletti a écrit :
> Mmmmh, in fact, this is not what I expect as a resource definition.
> Looks like sort of a "kind" definition.
>
>
>
> 2014/1/24 Boris Parak <xparak at mail.muni.cz>
> On Fri, Jan 24, 2014 at 4:25 PM, Jean Parpaillon
> <jean.parpaillon at free.fr> wrote:
> > Hi Boris,
> > Ooops, my mistake: I confirm erocci parses resource instance
> in a
> > "resources" object, not "kinds".
> > On the other hand, in JSON spec draft (version from april
> 29th 2013),
> > "id" and "title" are not in the "attributes" object, but at
> the same
> > level as "kind". Has it changed ?
> >
> > To be honest, I don't have any preference, we just have to
> agree and let
> > say the first implementation wins :)
>
>
> I'm actually not sure, Florian should be able to shed some
> light on
> this. I seem to remember a private discussion with him about
> occi.core
> attributes and how they are not actually that different from
> other
> attributes ... I know we decided to include UUID as
> 'occi.core.id' in
> attributes and as top-level 'id' to stay compatible.
> Otherwise, I
> prefer the all-in-one approach for attributes.
>
> > To clarify, in the document I use, the rendering is:
> > {
> > "resources": [
> > {
> > "kind":
> "http://schemas.ogf.org/occi/infrastructure#compute",
> > "id": "10c0d368-b096-4923-b21a-a9d026008d05",
> > "title": "ThisPC",
> > "attributes": {
> > "occi": {
> > "compute": {
> > "architecture": "x86",
> > "cores": 1,
> > "hostname": "pc001",
> > "memory": 5,
> > "speed": 4000,
> > "state": "inactive"
> > }
> > }
> > },
> > "id": "10c0d368-b096-4923-b21a-a9d026008d05"
> > }
> > ]
> > }
> >
> > Jean
>
>
> Boris
>
> > Le vendredi 24 janvier 2014 à 16:18 +0100, Boris Parak a
> écrit :
> >> Hello Jean, Augusto,
> >>
> >> may I join your debate? :-)
> >>
> >> A compute instance should be rendered as a resource not a
> kind, e.g.
> >>
> >> {
> >> "resources": [
> >> {
> >> "kind":
> "http://schemas.ogf.org/occi/infrastructure#compute",
> >> "attributes": {
> >> "occi": {
> >> "core": {
> >> "id": "10c0d368-b096-4923-b21a-a9d026008d05",
> >> "title": "ThisPC"
> >> },
> >> "compute": {
> >> "architecture": "x86",
> >> "cores": 1,
> >> "hostname": "pc001",
> >> "memory": 5,
> >> "speed": 4000,
> >> "state": "inactive"
> >> }
> >> }
> >> },
> >> "id": "10c0d368-b096-4923-b21a-a9d026008d05"
> >> }
> >> ]
> >> }
> >>
> >> (or in the attachment)
> >>
> >> > 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.
> >>
> >> We are taking the same approach in rOCCI.
> >>
> >> Cheers, Boris
> >>
> >> On Fri, Jan 24, 2014 at 3:45 PM, Jean Parpaillon
> >> <jean.parpaillon at free.fr> wrote:
> >> > 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
> >> >
> >> > _______________________________________________
> >> > occi-wg mailing list
> >> > occi-wg at ogf.org
> >> > https://www.ogf.org/mailman/listinfo/occi-wg
> >> >
> >
> > --
> > 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 --------------
{
"resources": [
{
"kind": "http://schemas.ogf.org/occi/infrastructure#compute",
"attributes": {
"occi": {
"core": {
"title": "ThisPC"
},
"compute": {
"architecture": "x86",
"cores": 1,
"hostname": "pc001",
"memory": 5,
"speed": 4000,
"state": "inactive"
}
}
}
}
]
}