[occi-wg] erocci
Boris Parak
xparak at mail.muni.cz
Fri Jan 24 10:18:40 EST 2014
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compute_rendering.json
Type: application/json
Size: 546 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140124/7e3788cc/attachment-0001.bin>
More information about the occi-wg
mailing list