August 2010 - occi-wg - lists.ogf.org

Dasein Cloud
by Thijs Metsch 23 Jun '13

23 Jun '13

Hi, Just to inform you that there is a cool project going on called Dasein-Cloud. http://dasein-cloud.sourceforge.net/ On the website it reads: Dasein Cloud is an Open Source Java API made available by enStratus Networks LLC under the terms of the Apache License 2.0. This API specifies cloud-independent interfaces for enabling an application to access resources across multiple clouds. If you are interested have a look - and it might be great to implement OCCI in their someday! Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

3 2

Reminder: concall today at 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 01 Sep '10

01 Sep '10

Hi, Just a quick reminder for our concall today! See the enclosed details to see how you can join! Topic for today is the discussion of the current revision in the wiki (including the changes made): http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRe… http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Infrastructu… Hope to talk to you soon! Cheers, -Thijs ------------------------------------------------------- To join the online meeting (Now from the Apple iPhone (R) and other smartphones!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=145498192&UID=1365030827&PW=NM2… 2. Enter your name and email address. 3. Enter the meeting password: 1234 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=145498192&UID=1365030827&PW=NM2… ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666

2 1

Model attributes and category attributes
by Ralf Nyren 31 Aug '10

31 Aug '10

Hi, The update of the core model introduced (at least) 3 new categories within the core scheme, http://schemas.ogf.org/occi/core# : http://schemas.ogf.org/occi/core#resource http://schemas.ogf.org/occi/core#link http://schemas.ogf.org/occi/core#action (The core&model page still use the purl.org scheme urls, update needed) These categories are not defined (as e.g. the resources in the infrastructure document) and thus it is not yet entirely clear which set attributes are associated with the categories. The link category is likely to define "occi.link.source", "occi.link.target" for example. We also have hard-coded attributes in the model, the "title" attribute of Kind, "id" and "summary" of Resource, etc. In short there are two ways an attribute can be defined. Which attributes of the core types should be static and which should be defined by categories? What criteria should determine where an attribute is defined? E.g. should Link source/target be defined in the model or by http://schemas.ogf.org/occi/core#link? regards, Ralf

1 0

New revision of the spec
by Thijs Metsch 27 Aug '10

27 Aug '10

Hi, I would like to point you to the newest version of the spec: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModels http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRe… http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Infrastructu… Some changes have happened including: * renaming Kind to Resource * Cleanup of namespace for schemes in the category and links * added some diagrams etc. This version includes a lot of rewording and should be more clear on many issues! Please review it and give us a first shot of feedback! Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

6 15

Updated - Cloud Computing Use Cases White Paper : "Moving to the Cloud" Table of Contents for V5
by Drussell4881 25 Aug '10

25 Aug '10

Thank you everyone for your feedback. Check out all the posts at ( http://groups.google.com/group/cloud-computing-use-cases ). In my initial post, I included items 1 thru 8. As you can see, the list has expanded to 17 potential topics / sub-topics for consideration. The next step is to assess the topics and determine which ones can be combined as well as to begin to expand each of the topic. The goal is to develop a paper which provides decision makers with the content to be able to make better decisions when "Moving to the Cloud". Suggestions for the content of V5 of the paper are as follows : 1 – Sources of workload + Datamining + Internal applications – such a payroll + Managing customer data – Medical records + Identity and Security + Websites - Either static ( product Catalogues, etc. ) or interactive ( Order Entry ) + Batch processing (time-insensitive stuff; like the entire story around genetics DB analysis, workflow-like workloads, Hadoop-like workloads), etc. 2 – Cloud types + Alignment to requirements – drives level of security needed + Mapping Cloud requirements to security, availability, accessibility, etc. 3 – Regulatory considerations + HIPAA, SOX, HIPPA, GLBA, Patriot ACT, ( examples and I am sure that are complementary examples from countries around the world ) + PIV-I, National IDs, etc + Industry Standards Organizations standards – ISO, etc. + Industry orgs such as agxml.org to reflect industry specific requirments + PCI for financial institutions, and the equivalent for the other countries + Location of data aligns with government requirements 4 – Types of use of the Cloud + Development of new applications + Testing of new applications and existing applications + Production running of existing applications (Consider migration; for example it requires true IaaS - PaaS alone may not be sufficent) 5 – Availability / Reliability of a Cloud environment + Ties back to the Service Level Agreements (see SLA section in V4 of the White Paper ) 6 – Portability of applications + From the IT environment to Cloud provider + From Cloud Provider A to Cloud Provider B + From the Cloud Provider to the IT environment + One of our members raised the point that portability may not be important, your thoughts? 7 – Workload volumes / Performance + Understanding the volumes of data to be transferred / accessed + User traffic + Vertical scaling versus horizontal scaling ( Look at legacy apps ) + Workload Optimization - how we can dynamically assess and optimize the resourcing and placement of workloads. 8 – Disaster recovery + Is the Cloud an alternative for disaster recovery? + If the Cloud Provider fails, what are the considerations? 9 - Migration Modes + Accessibility of data ( Must consider issues of data Synchronization and cross-site trusts) 10 - Development and Testing of services + Use a cloud environment to offload main site workload 11 - Business Cases / Business Models + Where is my market? + Which aspects are important to my customers? + Benefits of Cloud Computing compared to on-premise installations, etc. 12 - Common authentication, authorization and audit processing for an application + There was a question on Federated Identity - Which is best to follow, SAML or OpenID? 13 - Privacy 14 - Security + See V4 of the Cloud Computing Use Cases White Paper 15 - Service Level Agreements + See V4 of the Cloud Computing Use Cases White Paper 16 - Identity assurance of those authenticating to cloud resources + Trusted identify provisions + Ties back to portability 17 - Data Migration considerations as part of Governance + What is the format in which the data will be stored + Will the choice lock the consumer into the provider's format + What is the ability to migrate to another provider + Is there any migration support available, should the consumer choose to move their services from one provider to another These are an initial set of thoughts for topics which may become part of the Moving to the Cloud version of the Cloud Computing Use Cases White Paper. Once we have received feedback on the topics, plus added in the new topics for consideration, work will begin on developing the paper at .http://groups.google.com/group/cloud-computing-use-cases . The input to date has been very positive and I look forward to seeing the "Moving to the Cloud" paper evolve thru using the Open Community process. Please post your comments either on this site or the Cloud Computing Use Cases discussion group site. Thanks very much Dave

1 0

Chat...
by Edmonds, AndrewX 25 Aug '10

25 Aug '10

My id there is andy.edmonds should people want to start up a conversation. If others on the mailing list want to share their details just reply to this thread. Skype had the feature to create persistent public chats but doesn't seem to be supported any more. Guess we just have to wait for the good folks over at freenode. HTH, Andy ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

4 3

off topic qestion: occi archives?
by Csom Gyula 24 Aug '10

24 Aug '10

Hi! I donno where to post it so I put it here:) Is there a problem with the email archive? maybe moved? changed the policy? It used to list the archived items for the current month, too. However now, I cannot see the august ones... BTW: archive is quite useful (ie. for refencing or reviewing threads later)... Cheers, Gyula

3 3

Reminder: concall tomorrow 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 24 Aug '10

24 Aug '10

Hi, We will discuss the changes made to the core, intermediate resources and the HTTP Header Rendering stuff. I included the webex details in the Wiki: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… You can test the webex, and setup your browser using the following link: http://www.webex.com/lp/jointest/ I would like to encourage you to test your connection so we can start promptly and everybody can share a screen. Cheers, -Thijs -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax

1 0

Re: [occi-wg] Yet Another (non)Link Proposal
by Gary Mazz 18 Aug '10

18 Aug '10

Hi, Whichever proposal we go with, I think you have a legitimate request for the look ahead feature. cheers gary Csom Gyula wrote: > Hi! > > Thanks for the reply, now it's quite clear:) > > * Within the core there is no (rich) support for "relationship-relative roles", that is the entity > role (1) is specified by its Resource type and (2) could be further specified through Category > field(s). > > * When using extensions things might be different, ie. it might be possible to expose relationship- > relative roles by introducing a 'rel' attribute or kinda into Associations. Let me put my 'vote' on > adding such support:) > > Cheers, > Gyula > > ________________________________ > Feladó: gary mazzaferro [garymazzaferro(a)gmail.com<mailto:garymazzaferro@gmail.com>] > Küldve: 2010. augusztus 18. 8:18 > Címzett: Csom Gyula > Tárgy: Re: [occi-wg] Yet Another (non)Link Proposal > > Hi... inline again.. > > 2010/8/17 Csom Gyula <csom(a)interface.hu<mailto:csom@interface.hu>> > Hi! > > Thanks for your response! > > I've got the point: Rule2 below declares a multiplicity constraint (ie. one and only one... resource > could be referenced). However regarding extension/association, it is not yet clear where and > how you expose the roles. As stated below the role is specified by the extension, the question > is how:) > > Lets take a theoraticel example (emphasis put on theoratical:)). I want to introduce n-tier > semantics to OCCI through custom associations so that I define the following ones: > > * frontend references to a compute playing the frontend role (ie. UI) > * application references to a compute playing the application server role > * and finally db references to a compute acting as a database server > > For some reason application server (the entity) is linked to both the front end and db tier. Hence > it (the entity) will have 2 associations referencing to the same resource type (Compute) but with > different roles ('front end' and 'db'). So my extension has to differentiate between these > associations somehow. > > In occi, the roles for occi entities are defined by the Category field. To differentiate ('front end' and 'db') the entity's category information are read by the consumer. If the header contains only the one Category (application server), the other Categories (occi entities) are gathered through additional http GET requests. > > If the header contains multiple Category feilds are where it gets interesting.. If you are reading the http headers and the header supports multiple Categories (occi entities), the header must be transversed to locate it (the entity). This also means we need a way to reference the "in header" (local copy) of the Reference Resource. > > > > After all the question is: where and how can i declare these roles when I define the above 3 > custom associations? is there a 'role' an attribute of the Association? or is association a named > element and its name declares its role? rel attribute should be used? any extension must include > only one association (to a given entity)? or some other technique? > > I think you are looking for a way to preview aspects of the Reference and Association. Under current definition of the a Reference, there is only one implicitly defined relationship support, a "binding" between occi Resources. I do not believe there is any reason to explicitly define the relationship. > > For the Association, I can see potential for exposing the destination's relationship information. However, it adds cruft to interoperability, but so does ID, Title and Summary. I guess adding the 'rel' attribute can't hurt. > > Gyula > ________________________________________ > Feladó: Gary Mazz [garymazzaferro(a)gmail.com<mailto:garymazzaferro@gmail.com>] > Küldve: 2010. augusztus 17. 15:36 > Címzett: Csom Gyula > Másolatot kap: Edmonds, AndrewX; occi-wg(a)ogf.org<mailto:occi-wg@ogf.org> > Tárgy: Re: [occi-wg] Yet Another (non)Link Proposal > > Hi Csom, > > Thanks for the response answered inline > > Csom Gyula wrote: > >> Hi, >> I think using different terms for the different layers (entity model vs. http/html representation) >> is a practical thing:) There's one point though I couldn't catch in the proposal. The following >> rule is not intuitive for me: >> >> "Rule 2: One occi element is represented by one Reference." >> >> What does 'one' and 'represent' mean here? >> >> > In this definition, I meant only one (1) occi element can be represented > in a Reference field. In other proposals you could place multiple occi > elements in the link field. This is not the case here. > > >> * By the classical term a reference is made from one entity to another hence a reference >> doesn't represent entites rather relationships between them. >> >> > You make a good point and identify an hole in the proposal language. I > was making the assumption that References and Associations exist as part > of a Category, similar to the current link feild. That assumption should > be clearly defined as a Rule. So, the occi element including the > Reference is implicitly one end point of the the relationship and the > occi entity contained in the Reference is the other end point of the > relationship. This is also true of Associations. I'll clean that up today. > >> * Also by the classical term different references could be given to the same entity. That >> is supported by roles which specifie the entity roles within the relationship. Currently >> the OCCI entity model is simple enough so that Resources specify their roles. However >> when thinking of extension this might not be true... the same entity could play different >> roles... >> >> I might missed something..., so could you please clarify the above rule?:) >> >> > Extension are directed at Associations. The role of the Association is > defined by the extension and not the occi definition of the extension > "end point"/"point of presence". The fact that some URI is placed in > the Association field, already defines the relationship to the occi > element as an extension. I took that approach to limit the number of > explicitly defined roles and relationships. By placing the the > relationship with the extension, it allows extension greater flexibly in > terms of definition. > > We find a similar scenario with examining the 'rel' attribute > definitions in the IETF Link Header Proposal. There are some rel > attribute definitions that are significant for occi, while others are > irrelevant and some occi relationships are not described at all in the > 'rel' registry. I wanted to avoid that scenario. > > I hope I cleared up your questions. > >> Cheers, >> Gyula >> >> ________________________________ >> Feladó: occi-wg-bounces(a)ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>> [occi-wg-bounces(a)ogf.org<mailto:occi-wg-bounces@ogf.org><mailto:occi-wg-bounces@ogf.org<mailto:occi-wg-bounces@ogf.org>>] ; meghatalmazó: Gary Mazz [garymazzaferro(a)gmail.com<mailto:garymazzaferro@gmail.com><mailto:garymazzaferro@gmail.com<mailto:garymazzaferro@gmail.com>>] >> Küldve: 2010. augusztus 17. 12:04 >> Címzett: Edmonds, AndrewX >> Másolatot kap: occi-wg(a)ogf.org<mailto:occi-wg@ogf.org><mailto:occi-wg@ogf.org<mailto:occi-wg@ogf.org>> >> Tárgy: [occi-wg] Yet Another (non)Link Proposal >> >> Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1]. >> >> I think we need to revisit the reasons why we have linking in the first place. >> >> 1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi. >> 2) We also realized we would need to integrate vendor proprietary implementations. >> 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones. >> >> This was all decided prior to the introduction of the occi http header implementation. >> >> During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope. >> >> This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa. >> >> The Proposal: >> >> Name Changes: >> I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification. It would help limit confusion on the part of implementors and contributors. >> >> New Definitions: >> >> Reference: A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities. >> >> Association: A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi. >> >> Logic Rules: >> Reference: >> Rule 1: All References are part of the occi name space. >> Rule 2: One occi element is represented by one Reference. >> >> Association: >> Rule 1: Associations are used to extend occi with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions. >> Rule 2: Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space. >> Rule 3: Detailed information about the occi extension is only available after the extension is loaded be the extension consumer. >> Rule 4: The URI is mandatory for an Association. >> Rule 5: An occi Title attribute is mandatory for an Association. >> Rule 6: An occi Summary attribute is optional for an Association. >> >> >> Header Implementation Details: >> Remove the Link field from the header definition and replace it with the appropriate Reference and Association header field. >> >> Header Implementation Benefit: >> 1) Reduces Link attribute parsing complexity >> 2) Reduces provides better clarity of the information's purpose >> >> HTML5/RDFa Implementation Details: >> TBD >> >> I'll follow up with examples if there is interest >> >> cheers, >> gary >> >> >> >> >> [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link >> >> >> >> > > > >

1 0

Revisiting Fat Links
by Ralf Nyren 18 Aug '10

18 Aug '10

Hi all, After more discussions and writing a sample implementation of the Link as a resource concept I have come to realize its advantages. I do however still believe that Fat Links are necessary to be able to model all relevant use cases. Alexander pointed out that compared to his Thin Link proposal Fat Links would not integrate in a sufficiently clean way with the OCCI core model. In an attempt to address some of these concerns I have added a new section called "Revisiting Fat Links" to the Link & Linking page [1]. The changes from the previous Fat Links proposal are: - Link specialization is realized through the use of additional categories, i.e. the same way OCCI Resource resources are extended so is also the Link resource extended. - The class attribute is _not_ used to delegate the Link type. It merely says that the link MAY be specialized. It is an indication to the client to request Link details. - The rel attribute is used to delegate the type of the Link target, i.e. as suggested by the Web Linking draft. Comments welcome. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link

3 5