November 2013 - occi-wg - lists.ogf.org

Re: [occi-wg] XML to represent an instance
by Augusto Ciuffoletti 29 Nov '13

29 Nov '13

>From a very intuitive (i.e., unformal) point of view, it is a very compact way to describe an resource together with outgoing links: think of a graph representation. I agree with you that this offers an embarrassing alias for the operation of creating link, clearly more convenient than the "official" way. I decided to use this alternative exactly for that reason: it is very attractive, so probably the most frequently used. But I found the same point you did: once created, I have no reference for the link. So here is the question: is the "in line" creation of a link (as in the http rendering paper, sect. 3.4.5) conceptually acceptable (and why, we may have overlooked some relevant detail), or not? 2013/11/12 Jean Parpaillon <jean.parpaillon(a)free.fr> > Hi Augusto, > > > Le 12/11/2013 11:40, Augusto Ciuffoletti a écrit : > > ... > > > > > > > > -) inline links are introduced in the "infrastructure" document. I > > hope > > > that my interpretation is correct. It is true that in this way a > > link is > > > hidden inside the resource. So this is a critical issue in the > > > infrastructure document that should be resolved, or simply > clarified > > > > > > > Could you point the section where it appears ? I can not find it. > > > > > > Sorry, it was in the "http rendering" document. This is the link in > > March 2013 revision: > > GFD-P-R.185 > > March 22, 2013 > > 3.4.5 Handling Link instances > > > > Ok, thanks. From what I can understand, an inline link can not be > retrieved in the general links collection. This looks weird for me but I > have not concrete case in mind. > > > ... > > Regards, > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 > im: jean.parpaillon(a)gmail.com > skype: jean.parpaillon > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > -- > Augusto Ciuffoletti > Dipartimento di Informatica > Università di Pisa > 56100 - Pisa (Italy) <http://www.linkedin.com/in/jeanparpaillon/en> >

2 3

Fwd: [CSC] [TG3] Final CSC Report v0.99 for editorial comments only
by Sill, Alan 26 Nov '13

26 Nov '13

Editorial comments to the Cloud Standards Coordination committee by tomorrow on this document would be appreciated. Alan Begin forwarded message: From: Emmanuel Darmois <emmanuel.darmois(a)COMMLEDGE.COM<mailto:emmanuel.darmois@COMMLEDGE.COM>> Subject: [CSC] [TG3] Final CSC Report v0.99 for editorial comments only Date: November 26, 2013 at 3:38:55 PM CST To: <CLOUD_STANDARDS_COORDINATION(a)LIST.ETSI.ORG<mailto:CLOUD_STANDARDS_COORDINATION@LIST.ETSI.ORG>> Reply-To: Emmanuel Darmois <emmanuel.darmois(a)COMMLEDGE.COM<mailto:emmanuel.darmois@COMMLEDGE.COM>> Bonjour, You will find attached the CSC Final Report in v0.99. And also the Excel file resulting from the review of comments. The report is for “sanity check”: - only editorial comments (no remarks on content any more) - check h-the proper implementation of (your) comments. If you have observations, please send them before Wednesday November 27th 18:00 CET. After that date, the document will be edited in version 1.0 and sent to the Commission. Thanks in advance. Emmanuel ________________________________ Mail archive for CLOUD_STANDARDS_COORDINATION can be browsed at the following url : http://list.etsi.org/CLOUD_STANDARDS_COORDINATION.html To unsubscribe from this list send a mail to listserv(a)list.etsi.org<mailto:listserv@list.etsi.org> with the following text in the body: UNSUBSCRIBE CLOUD_STANDARDS_COORDINATION ________________________________

1 0

Fwd: [Dipartimento] Three research positions open at the University of Pisa, Italy
by Augusto Ciuffoletti 24 Nov '13

24 Nov '13

FYI ---------- Forwarded message ---------- From: Antonio Brogi <seaclouds(a)di.unipi.it> Date: 2013/11/23 Subject: [Dipartimento] Three research positions open at the University of Pisa, Italy To: dipartimento(a)di.unipi.it Three temporary research positions *with competitive salaries *are open at the Department of Computer Science at the University of Pisa, Italy. The three positions are funded by the European research project SeaClouds “Seamless adaptive multi-cloud management of service-based applications”. The official call for applications will be opened in the last week of November 2013 or in the first week of December 2013. Once the official calls will be published, candidates will have to promptly apply since each call will remain open only for 7 days. For more information please visit: http://www.di.unipi.it/~seaclouds/ _______________________________________________ This list does not forward message attachments Dipartimento mailing list Dipartimento(a)di.unipi.it http://mnode.di.unipi.it/mailman/listinfo/dipartimento -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

1 0

ETSI deliverables about network virtualization
by Augusto Ciuffoletti 19 Nov '13

19 Nov '13

For those interested in NV, ETSI has recently released some docs on the topic. Go to http://www.etsi.org/technologies-clusters/technologies/nfv and select the "specifications" label. Free access. -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

1 0

Fwd: xml for occi-monitoring
by Augusto Ciuffoletti 12 Nov '13

12 Nov '13

Hi all, me and Jean had a conversation that happened to be "private", instead of "public" as in our intentions. My fault. So here it is... Augusto ---------- Forwarded message ---------- From: Jean Parpaillon <jean.parpaillon(a)free.fr> Date: 2013/11/12 Subject: Re: [occi-wg] xml for occi-monitoring To: Augusto Ciuffoletti <augusto(a)di.unipi.it> Le 12/11/2013 12:36, Augusto Ciuffoletti a écrit : > Ok, this is a roadmap item! Note that this discussion is now between me > and you, though... This is bad point. Would you mind transfer it to the ml ? Jean > > > 2013/11/12 Jean Parpaillon <jean.parpaillon(a)free.fr > <mailto:jean.parpaillon@free.fr>> > > Hi > > Le 06/11/2013 10:33, Augusto Ciuffoletti a écrit : > > Replies are inline > > > > 2013/11/1 Jean Parpaillon <jean.parpaillon(a)free.fr > <mailto:jean.parpaillon@free.fr> > > <mailto:jean.parpaillon@free.fr <mailto:jean.parpaillon@free.fr>>> > > > > Hi Augusto, > > I had a look at your document and I have some comments: > > > > 1) as of RFC2606, example.com <http://example.com> > <http://example.com> and example.org <http://example.org> > > <http://example.org> are reserved domain for > > documentation purposes; > > > > > > touché > > > > > > 2/ While it's perfectly fine for me to let provider decide > metrics he > > wants to expose, I think a minimum of interoperability requires a > > standardized list of them. > > > > It would be a hard task to make the job again which was done > succesfully > > over the years by SNMP community. I am thinking about a way to > translate > > SNMP MIB variables into OCCI. > > We may define MIBs as a mixin to associate to a sensor, for > instance: > > > > <occi:mixin title="SNMP MIB" > > scheme="http://schemas.ogf.org/occi/monitoring#" term="mib" > > use="optional" > > > <occi:applies scheme="http://schemas.ogf.org/occi/monitoring#" > > term="sensor" /> > > <occi:attribute name="name" type="string" /> > > <occi:attribute name="id" type="string" /> > > </occi:mixin> > > > > This is not complete, of course, but would rely on SNMP set of > metrics > > for providing a good level of interoperability between monitoring > > providers. > > > > > > Yes, this is true. The point for me is to what extent a *single* > > standardization document has to detail. > > > > For instance, think to the RTP protocol: it is designed to transport > > multimedia, but there is no effort to define what is a frame. All this > > is demanded to extensions, and there are a lot, and more are coming. > > > > I have a similar idea of OCCI: include a definition only of concepts > > (types) that are strictly needed to make it self contained. If I say > > that an attribute is a number, I must say what a number is. In my > case I > > have time attributes, and I have to define what time is (note, I use > > only strings and integers, since this seems to be the limited toolset > > available). > > > > Extensions to the bare minimum should included in companion documents: > > they can change over time, and the companion document may be > superseded, > > or deprecated. But the foundations are intact. > > > > So, in my mind it is ok to create a document "OCCI extension to > > represent networks as MIB", and to take advantage of other long > > elaborated results that aim at describing resources. But leaving this > > distinct from a "foundational" document. > > > > I agree with that. Monitoring and OCCI<->MIB spec must be separated. But > as the latter one would widely depend on monitoring categories, I would > tend to begin this spec ASAP to validate the monitoring spec. > > > Bye! > > > > Augusto > > Ciao > Jean > > > > > Best regards, > > Jean > > > > Le 18/10/2013 15:48, Augusto Ciuffoletti a écrit : > > > Dear all, > > > > > > I have added to the xml-data-format branch an example of the xml > > that a > > > provider (ACME) might add to specify the kind of monitoring > options it > > > offers. I recall that one of the key features of the > approach is to > > > leave the provider the freedom to define the available > building blocks > > > for the monitoring services. The file > (occi-monitoring-acme.xml) is > > > attached to this e.mail, together with an updated revision > of the > > > occi-monitoring.xml. > > > > > > I'll be happy to read any comment on this, especially on the > > > appropriateness of the namespaces I have chosen: this is a > > critical part > > > that cannot be tested with xmllint... > > > > > > Augusto > > > > > > PS: apologies if a real ACME provider exists... > > > > > > -- > > > Augusto Ciuffoletti > > > Dipartimento di Informatica > > > Università di Pisa > > > 56100 - Pisa (Italy) > > > > > > > > > _______________________________________________ > > > occi-wg mailing list > > > occi-wg(a)ogf.org <mailto:occi-wg@ogf.org> > <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> > > > https://www.ogf.org/mailman/listinfo/occi-wg > > > > > > > > > -- > > Jean Parpaillon > > Open Source Consultant > > Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086> > <tel:%2B33%206%2030%2010%2092%2086> > > im: jean.parpaillon(a)gmail.com > <mailto:jean.parpaillon@gmail.com> <mailto:jean.parpaillon@gmail.com > <mailto:jean.parpaillon@gmail.com>> > > skype: jean.parpaillon > > linkedin: http://www.linkedin.com/in/jeanparpaillon/en > > > > _______________________________________________ > > occi-wg mailing list > > occi-wg(a)ogf.org <mailto:occi-wg@ogf.org> > <mailto:occi-wg@ogf.org <mailto:occi-wg@ogf.org>> > > https://www.ogf.org/mailman/listinfo/occi-wg > > > > > > > > > > -- > > Augusto Ciuffoletti > > Dipartimento di Informatica > > Università di Pisa > > 56100 - Pisa (Italy) > > > -- > Jean Parpaillon > Open Source Consultant > Phone: +33 6 30 10 92 86 <tel:%2B33%206%2030%2010%2092%2086> > im: jean.parpaillon(a)gmail.com <mailto:jean.parpaillon@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(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

1 0

XML to represent an instance
by Augusto Ciuffoletti 12 Nov '13

12 Nov '13

Dear all, Jean has recently proposed the formalization of the core model as an XSD schema. This is useful as a clean description of the model, and makes possible to validate the specialization of this model to represent more specific models. We have two examples for this: infrastructure and monitoring described as compliant XML files. I considered another use of XML for the representation of an *instance* of a system (a monitoring system in my case). This kind of representation has two relevant functions: one is that it gives the ability to check certain requirements (e.g., that required attributes are present), the other is that it can drive the activity of the cloud management system. My question: is this related with the OCCI roadmap? To go to the attached XML, it is a representation of the example given in the document (the figure is also attached). Some relevant options I use: -) Mixins are represented as distinct stanzas in the XML document. -) Links are defined "inline", inside the origin resource Of course, it is possible to write an XSD, but I'd like to collect opinions about the overall approach. Comments? -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

2 3

OCCI XML schema updates
by Jean Parpaillon 01 Nov '13

01 Nov '13

Hi all, Thanks to your feedback, and specially Augusto's, I have updated the XML description of OCCI. I have pushed them to the xml-data-format branch of ogf repository. == Summary of modifications: 1/ added a 'manifest' top level element to group entities. Rationale: with HTTP transport, the semantic of HTTP commands can be used by a consumer to request creation of resources. In a generic transport (file, for instance), we need to specify a container for each kind of request. 2/ add a status attribute to extensions. I've been inspired by XMPP way of extending the protocol: http://xmpp.org/extensions/xep-0001.html#approval-std == Unresolved questions: As I've seen with the example of monitoring instance description, a resource with a lot of mixins can be difficult to read (for a human) as there is no distinction on the origin of attributes. In text/plain and text/occi description, this list is flat, due to the HTTP protocol. I propose attributes to be group by mixin in an entity description. For instance: <occi:resource ... > <occi:kind scheme="..." term="..." />  <occi:attribute name="attr1" value="value1" /> <occi:attribute name="attr2" value="value2" /> <occi:attribute ... /> <occi:mixin scheme="..." term="..." >  <occi:attribute name="attr4" value="value4" /> </occi:mixin> </occi:resource> Best regards, -- Jean Parpaillon Open Source Consultant Phone: +33 6 30 10 92 86 im: jean.parpaillon(a)gmail.com skype: jean.parpaillon linkedin: http://www.linkedin.com/in/jeanparpaillon/en

1 0

xml for occi-monitoring
by Augusto Ciuffoletti 01 Nov '13

01 Nov '13

Dear all, I have added to the xml-data-format branch an example of the xml that a provider (ACME) might add to specify the kind of monitoring options it offers. I recall that one of the key features of the approach is to leave the provider the freedom to define the available building blocks for the monitoring services. The file (occi-monitoring-acme.xml) is attached to this e.mail, together with an updated revision of the occi-monitoring.xml. I'll be happy to read any comment on this, especially on the appropriateness of the namespaces I have chosen: this is a critical part that cannot be tested with xmllint... Augusto PS: apologies if a real ACME provider exists... -- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)

2 1