- occi-wg - lists.ogf.org

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

Another proposal on Linking
by Ralf Nyren 17 Aug '10

17 Aug '10

While analyzing the new Link & Linking proposal I went back to where we started and tried to see what benefits the proposal would have. Except for link attributes through link specialisation I failed to see any real benefits. I mean it is indeed tempting to say that a Link is a REST resource and therefore we can apply CRUD (POST/GET/PUT/DELETE) operations directly on links. But why would we want to do that? A link is not very useful on its own and what is it we cannot do with the simpler approach? Based on this reasoning I wrote up "another proposal" and added to the Link & Linking wiki page [1]. It is indeed very simple (but I like simple!) and I believe it can do all things we realistically would want to do with the Fat Link approach. I am very much looking forward to your comments. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link

3 9

OCCI Categories and Types
by Edmonds, AndrewX 17 Aug '10

17 Aug '10

Hi all, Yesterday Alexander and I spent some time exploring and discussing OCCI categories. These categories make up the type system for OCCI and I've documented our discussion here [1]. We'd love to hear feedback, comments etc! Andy [1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Catego… ------------------------------------------------------------- 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.

6 19

Link & Linking
by Ralf Nyren 17 Aug '10

17 Aug '10

I studied your document on Link & Linking [1]. Nice write-up! When a Link is turned into a resource and thus exposed to CRUD semantics it will only be valid in the response to a GET request of an associated Resource, right? That is, using POST/GET/PUT/DELETE with e.g. a compute resource any Link headers will only be present in the GET response? If so we solve the problems of updating and removing links although we still have the the side effects when deleting a resource with associated links. I.e. that the DELETE operation of a resource should remove any associated links to avoid dangling links. Another problem with Link as a resource is that now there can be circular links and links pointing to other links. I think a problem here is that you try to model the concept of bi-directional links on top of Web Links which are strictly unidirectional (correct my if I am wrong). When you do this an important question to ask is what OCCI really is. Is it an interface or is it a representation model? If we decide OCCI is limited to be an interface I say unidirectional links are all we need. It is not up to OCCI to represent the relation between resources for persistent storage, it should merely be able to _display_ links to other resources. It is not like an IaaS provider would use OCCI as its internal representation format. Now, look at the analogy with web pages. A web page is a resource, that is easy to see and CRUD semantics apply as best they ever could. A web page may have links to other web pages, unidirectional links. Thus links will be removed when the resource is removed and referential integrity is not guaranteed. Why not apply the same model in OCCI? We leave the issue of referential integrity in the hands of the IaaS provider. If we create a compute resource with a link to a storage resource and then view the storage resource it is up to the provider to decide if a reverse link to the compute resource should be included in the response. Sorry if this last part was a bit confusing. I will add a proposal of my own to the Link & Linking document so we have a basis for discussion. regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link

2 1

Reminder: concall tormorrow at 10am EDT, 4pm CET, 3pm BST
by Thijs Metsch 17 Aug '10

17 Aug '10

Hi, We will continue the discussion from last week and will look into Categories, Links and Attributes some more. Following that we will have to come up with some action items to move on with the next revision. I included the webex details in the Wiki: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… 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

HTTP Header Serialization Format, use of Attribute header
by Ralf Nyren 17 Aug '10

17 Aug '10

Hi, Reading the updated spec on Http Header Rendering [1] I see you have changed the way attributes are represented in the HTTP header. In the latest docbook spec OCCI resource attributes are specified using the "Attribute" header, e.g.: GET /compute/xxx HTTP/1.0 HTTP/1.0 200 OK Attribute: occi.compute.speed=2.0 Attribute: occi.compute.memory=1.0 In the latest spec however it would look like this instead: HTTP/1.0 200 OK occi.compute.speed: 2.0 occi.compute.memory: 1.0 What is the motivation behind this change? I believe the Attribute header is a much more clean approach since it does not pollute the HTTP header namespace with (perhaps) arbitrary names (you have to consider vendor extensions as well). regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRe…

4 15

Cloud Computing Use Cases White Paper : "Moving to the Cloud" proposed Table of Contents for V5.
by Drussell4881 16 Aug '10

16 Aug '10

An initial post has been made to start a discussion on the development of the Table of Contents ( TOC ) for the Moving to the Cloud iteration of the Cloud Computing Use Cases White Paper at ( http://groups.google.com/group/cloud-computing-use-cases ). Version 4 of the paper is located at http://www.scribd.com/doc/18172802/Cloud-Computing-Use-Cases-Whitepaper or through the http://cloudusecases.org/ site. Some of the suggestions that have come in for V5 of the paper are as follows : 1 – Sources of workload Datamining Internal applications – such a payroll Managing customer data – Medical records 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 ) Industry Standards Organizations standards – ISO, etc. Location of data aligns with government requirements 4 – Types of use of the Cloud Development of new applications Testing of new applications 5 – Availability / Reliability of a Cloud environment Ties back to the Service Level Agreements 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 7 – Workload volumes / Performance Understanding the volumes of data to be transferred / accessed 8 – Disaster recovery Is the Cloud an alternative for disaster recovery? If the Cloud Provider fails, what are the considerations? 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 . I ask that you input your thoughts on what would be important to you as you would consider “Moving to the Cloud” either on this site or the Cloud Computing Use Cases discussion group site. Thanks very much Dave

1 0

Re: [occi-wg] IO Console Resource -- Infrastructure docRe: IO Console Resource -- Infrastructure doc proposal
by Gary Mazz 12 Aug '10

12 Aug '10

Hi, Below is a fragment of an email from Csom Gyula which addressed many issues. Thijs ask to have this issue carved out and on a separate email thread. This fragment was in response to a proposal for text and graphical consoles as an occi resource. A Console Resource was proposed to help support features commonly found in private cloud implementations based on hypervisor and blade server configurations . After there was some support for the proposal, I elected to work out some use case details to ensure implementation practices and common architectural models were captured. The use cases would probably be better served in some sort of spreadsheet, but this is what I have for the moment. I'll follow up with diagrams if more interest is gained in the proposal. This is a work in progress and is likely to incorporate more detail within the next week Cheers gary Fragment from email by Csom Gyula "Re: [occi-wg] New revision of the spec: > [7] Graphics: I agree with Gary, console is a must:) His spec is > definitve... here let me add just > some notes: > * We are using KVM/QEMU as the hypervisor so I can confirm that > KVM/QEMU provides graphical terminal support, namely VNC:) > * Security is an issue at least in two ways. First the terminal gives > access to the running compute resource hence it needs password > protection or such. Second the terminal > access operates on the host level not on the vm level. That is the > terminal address would > be the IP of the physical host the vm is running on. Generally it is > not a secure thing > to give direct access to interna hostl infrastructure. For instance > in our solution (currently in development) we use a VNC proxy that > hides the internal locations. > * Isn't occi.console.status the same as (or projection of) the > socci.compute.status? It could > be a useful information though. I guess it should be dinamically > queried from the corresponding > compute resource. > * Either the console should be the part of the compute resource or it > should link to the compute resource it belongs to, that is: > * either console should be moved under the compute namespace (ie. > occi.compute.console.xxx) > * or there must be a bidirectional link between the two > (occi.console.compute_link -> compute > and occi.compute.console_link -> console or such) > Some good notes @Gary can you respond? How do you feel about the subject if those attributes are mandatory or optional? GM> I think part of the issue is our deployment use case model that is somewhat incomplete in terms of a console. *Computer **and Blade **Platform Use Cases* *Generalized **VM Execution **Use Cases* USE CASE] A VM executes on single computer platform with a single or multiple cpu cores. USE CASE] A VM executes on blade platform with a single or multiple cpu cores. *Generalized IO Console Configuration **Use Cases* USE CASE] A single computer platform supports one or more serial ports for console I/O USE CASE] A single compute platform supports one or more video outputs and one keyboard input USE CASE] A blade platform supports one or more serial ports for console I/O USE CASE] A blade platform supports one more video output and one keyboard input *Generalized IO Console Client to IO Console Server Connectivity Use Cases* USE CASE] A blade platform management controller presents blade's video outputs and keyboard inputs via a network protocol including VNC, RDP and XWindows USE CASE] A blade platform management controller presents blade's serial ports via a network protocol including TELNET and SSH USE CASE] A KVM device controller presents single computer's video outputs and keyboard inputs via a network protocol including VNC, RDP and XWindows USE CASE] A Terminal Server presents a single computer's serial ports via a network protocol including TELNET and SSH * *Hypervisor Software Use Cases** USE CASE] A Hypervisor Software executing on a single blade presents VM's video outputs and keyboard inputs via a network protocol including VNC, RDP and XWindows USE CASE] A Hypervisor Software executing on a single blade presents a VM's serial ports via a network protocol including TELNET and SSH USE CASE] A Hypervisor Software executing on a single blade element presents VM's video outputs and keyboard inputs via a network protocol including VNC, RDP and XWindows USE CASE] A Hypervisor Software executing on a single blade element presents a VM's serial ports via a network protocol including TELNET and SSH *IO Console Sharing Use Cases* USE CASE] More than one user may access a blade's platform management controller's presented blade's video outputs and keyboard inputs via a network (console instance sharing) USE CASE] More than one user may access a blade's platform management controller's presented blade's serial ports via a network (console instance sharing) USE CASE] More than one user may access a Terminal Server's presented single compute serial port via a network (console instance sharing) USE CASE] More than one user may access a KVM device's presented single compute serial port via a network (console instance sharing) *IO Console Configuration Use Cases* USE CASE] Network Address of Terminal Server's presented single computer's serial port can be set by VM configuration USE CASE] Network port number of Terminal Server's presented single computer's serial port can be set by VM configuration USE CASE] Network Address of Terminal Server's presented single computer's serial port can be set by Cloud Provider Administration USE CASE] Network port number of Terminal Server's presented single computer's serial port can be set by Cloud Provider Administration USE CASE] Network Address of Terminal Server's presented single computer's serial port can be read by Cloud User(s) though VM configuration USE CASE] Network port number of Terminal Server's presented single computer's serial port can be read by Cloud Provider Administration though VM configuration USE CASE] Terminal Server's Network Address presenting a single computer's serial port can be is common across all Terminal Server's serial ports USE CASE] Network Address of KVM's presented single computer's graphical console can be set by VM configuration USE CASE] Network port number of KVM's presented single computer's graphical console can be set by VM configuration USE CASE] Network Address of KVM's presented single computer's graphical console can be set by Private Cloud Administration USE CASE] Network port number of KVM's presented single computer's graphical console can be set by Cloud Provider Administration USE CASE] Network Address of KVM's presented single computer's graphical console can be read by Cloud User(s) though VM configuration USE CASE] Network port number of KVM's presented single computer's graphical console can be read by Cloud Provider Administration though VM configuration USE CASE] KVM's Network Address presenting a single computer's graphical console can be is common across all Terminal Server's serial ports USE CASE] Network Address of a blade's platform management controller's presented blade's serial port can be set by VM configuration USE CASE] Network port number of a blade's platform management controller's presented blade's serial port can be set by VM configuration USE CASE] Network Address of a blade's platform management controller's presented blade's serial port can be set by Cloud Provider Administration USE CASE] Network port number of a blade's platform management controller's presented blade's serial port can be set by Cloud Provider Administration USE CASE] Network Address of a blade's platform management controller's presented blade's serial port can be read by Cloud User(s) though VM configuration USE CASE] Network port number of a blade's platform management controller's presented blade's serial port can be read by Cloud Provider Administration though VM configuration USE CASE] Terminal Server's Network Address presenting a blade's serial port can be is common across all a blade's platform management controller's serial ports presented USE CASE] Network Address of a blade's platform management controller's presented blade's graphical console can be set by VM configuration USE CASE] Network port number of a blade's platform management controller's presented blade's graphical console can be set by VM configuration USE CASE] Network Address of a blade's platform management controller's presented blade's graphical console can be set by Cloud Provider Administration USE CASE] Network port number of a blade's platform management controller's presented blade's graphical console can be set by Cloud Provider Administration USE CASE] Network Address of a blade's platform management controller's presented blade's graphical console can be read by Cloud User(s) though VM configuration USE CASE] Network port number of a blade's platform management controller's presented blade's graphical console can be read by Cloud Provider Administration though VM configuration USE CASE] Terminal Server's Network Address presenting a blade's graphical console can be is common across all a blade's platform management controller's serial ports presented *IO Console Authentication Use Cases* USE CASE] A Terminal Server's presented single compute serial port has only one credential for all Private Cloud Administrators (user/customer) accessing the port USE CASE] A Terminal Server's presented single compute serial port has only one credential for each Private Cloud Administrator (user/customer) accessing the port USE CASE] A Terminal Server has only one credential for all Private Cloud Administrators (user/customer) accessing all presented single compute serial ports USE CASE] Terminal Server's presented single compute serial port's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] Terminal Server's presented single compute serial port's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] Terminal Server's presented single compute serial port's credentials can be set with a external management application by the Cloud Administrator USE CASE] Terminal Server's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] Terminal Server's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] Terminal Server's credentials can be set with a external management application by the Cloud Administrator USE CASE] A KVM's presented single computer's graphical console has only one credential for all Private Cloud Administrators (user/customer) accessing the port USE CASE] A KVM's presented single computer's graphical console has only one credential for each Private Cloud Administrator (user/customer) accessing the port USE CASE] A KVM has only one credential for all users accessing all presented computer's graphical consoles USE CASE] KVM's presented single computer's graphical console's credentials can be set with the VM configuration by the Cloud Administrator USE CASE] KVM's presented single computer's graphical console's credentials can be set with the VM configuration by the Private Cloud Administrators (user/customer) USE CASE] KVM's presented single computer's graphical console's credentials can be set with a external management application by the Cloud Administrator USE CASE] KVM's credentials can be set with the VM configuration by the Cloud Administrator USE CASE] KVM's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] KVM's credentials can be set with a external management application by the Cloud Administrator USE CASE] A blade's platform management controller's presented blade serial ports has only one credential for all Private Cloud Administrators (user/customer) accessing the port USE CASE] A blade's platform management controller's presented blade serial ports has only one credential for each Private Cloud Administrator (user/customer) accessing the port USE CASE] A blade's platform management controller has only one credential for all Private Cloud Administrators (user/customer) accessing all presented blade serial ports USE CASE] A blade's platform management controller's presented blade serial port's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] A blade's platform management controller's presented blades serial port's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] A blade's platform management controller's presented blade serial port's credentials can be set with a external management application by the Cloud Provider Administrator USE CASE] A blade's platform management controller's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] A blade's platform management controller's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] A blade's platform management controller's credentials can be set with a external management application by the Cloud Provider Administrator USE CASE] A blade's platform management controller's presented blade's graphical console has only one credential for all Private Cloud Administrators (user/customer) accessing the port USE CASE] A blade's platform management controller's presented blade's graphical console has only one credential for each Private Cloud Administrator (user/customer) accessing the port USE CASE] A blade's platform management controller has only one credential for all Private Cloud Administrators (user/customer) accessing all presented blade's graphical consoles USE CASE] A blade's platform management controller's presented blade's graphical console's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] A blade's platform management controller's presented blade's graphical console's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] A blade's platform management controller's presented blade's graphical console's credentials can be set with a external management application by the Cloud Provider Administrator USE CASE] A blade's platform management controller's credentials can be set with the VM configuration by the Cloud Provider Administrator USE CASE] A blade's platform management controller's credentials can be set with the VM configuration by the Private Cloud Administrator (user/customer) USE CASE] A blade's platform management controller's credentials can be set with a external management application by the Cloud Provider Administrator **Limits * *Desktop Virtualization created by the executing operating system in a VM is not in the scope of this use case model. **Comments:* * I'm looking into a more robust way of defining the security identifier and credentials , I'm also looking at an interoperable way to incorporate the configuration issues into OCCI. I put a proposal together if we all agree on the use cases. -------- Original Message -------- Subject: Re: IO Console Resource -- Infrastructure doc proposal Date: Wed, 04 Aug 2010 14:56:53 -0600 From: Gary Mazz <garymazzaferro(a)gmail.com> To: Andy Edmonds <andy.edmonds(a)gmail.com> CC: Thijs Metsch <tmetsch(a)platform.com>, "occi-wg(a)ogf.org" <occi-wg(a)ogf.org> References: <4C593B8D.7000103(a)gmail.com> <E2AC825D4FC7764DA86D9C8ECA27A2DE0420AFB8(a)catoexm05.noam.corp.platform.com> <4C598503.4090508(a)gmail.com> <AANLkTinWcmxnoEsNxhjBEJe59=Jbo3UjhwPFKVqiWFy9(a)mail.gmail.com> I thought I added the mailing list to the email thread. :0 I'll repost.. with the original pdf attached. -g Andy Edmonds wrote: > Please can this discussion happen on the mailing list - it goes > completely against the grain of an "open community". > > Andy > andy.edmonds.be <http://andy.edmonds.be> > > > On Wed, Aug 4, 2010 at 18:19, Gary Mazz <garymazzaferro(a)gmail.com > <mailto:garymazzaferro@gmail.com>> wrote: > > > State and Status good question.. > > State is an attribute set by the user to enable or disable the > operation of the console instance. > Status is the current operational disposition of the console instance. > > I think this is a MUST. XEN, ESXi, VirtualBox will not configure a > virtual machine without the console set. I'm not sure, but I also > believe the same is true for qemu. Without the console, we exclude > many private cloud configurations. > > The big issue is what happens when the user moves a configuration > (VM) to a provider that does not support the feature. What gets > reported back ? Does the provider maintain the configuration > (ala OVF like), but shows the instance status as an unsupported > resource. Or, does the provider ignore the resource and report > back "unknown" ? If the resource is ignored, how will that > impact VM instance configuration changes and teleportability of > the VM to another platform/provider ? Right now I cannot see > resources or configurations being discarded just because the > platform doesn't support the resource. Resources and > configurations must be maintained, even though unsupported, to > properly support teleportation. > > -g > > > > Thijs Metsch wrote: > > > Overall looks good...Just wondering why there is a state and > status? one immutable and one mutable? > > But would be cool if you could post it to the list as well... > > Also we should try to figure out if this is a MUST, SHOULD or > MAY section according to RFC2116... > > Thanks Gary. > > -Thijs > > -----Original Message----- > From: Gary Mazz [mailto:garymazzaferro@gmail.com > <mailto:garymazzaferro@gmail.com>] > Sent: Wed 04-Aug-10 12:06 > To: Thijs Metsch; Andy Edmonds > Cc: Subject: IO Console Resource -- Infrastructure > doc proposal > > Hi, > > I've created a new section for the infrastructure document > for the IO > Console. The console is very important for virtual machine > configurations. > > I've attached the section for the document. Please review and > comment if > considered for inclusion. > > -g > > > > >

1 0

Removing associations between resources
by Ralf Nyren 11 Aug '10

11 Aug '10

Hi again, Reading the specs I cannot quite figure out how to remove an association between one resource and another. As far as I understand PUT can be used to add a new or change an existing association, i.e. using Link headers. But how to remove an association? Reading the Wiki [1] I found some new text which indicates that DELETE somehow can be used to remove associations as well as resources. The described semantics seemed to be rather complicated. You have probably thought a lot about this already but from my point of view any operation which irreversibly deletes/destroys a resource should have as simple semantics as possible. Using DELETE to remove associations seem dangerous to me. What are your thoughts on this matter? regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/CoreAndModel…

6 12

Fwd: New revision of the spec
by Alexander Papaspyrou 10 Aug '10

10 Aug '10

Reply-all, Alexander, Reply-all... Anfang der weitergeleiteten E-Mail: > Von: Alexander Papaspyrou <alexander.papaspyrou(a)tu-dortmund.de> > Datum: 10. August 2010 16:12:33 MESZ > An: Csom Gyula <csom(a)interface.hu> > Betreff: Re: [occi-wg] New revision of the spec > > Csom, > > Am 04.08.2010 um 23:22 schrieb Csom Gyula: > >> [5] Id assignment: Generally speaking server assigned ids doesn't provide a robust solution. >> What if the client lost the connection? It can lead to zombie resources... Think of system >> integration and cloud management automation... Either unique names or sequences (like >> in RDBMS) could be supported. > > Could be specified as a UUID URN. > > Best, > Alexander > > -- > Alexander Papaspyrou > alexander.papaspyrou(a)tu-dortmund.de > > -- Alexander Papaspyrou alexander.papaspyrou(a)tu-dortmund.de

1 0