I'd like to pick up on this request from Jin. I believe Alexander had offered access to an instance of something testable at TUDO - any others? In general, I would like to request help working through the test cases documented for NIST SAJACC at http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/SA... under "Working Documents and Artifacts" Note they have downloadable example code for demonstrations with other standards - see last item on that list! Alan Begin forwarded message:
From: "Tong, Jin"
Date: May 4, 2011 4:43:12 PM GMT+02:00 To: "Edmonds, AndrewX" , "Sill, Alan" Cc: Ralf Nyren , "Hogan, Michael D." , "Sokol, Annie W." , "Liu, Fang" , "Badger, Mark Lee" , Thijs Metsch , Alexander Papaspyrou , Alexis Richardson Subject: RE: OCCI test server Andy,
I just replied Alan's message and copied to occi-wg mailing list to give a little background of our testing work. In terms of timing, the next major check point is September/October this year. If we can get to an OCCI endpoint that can actually facilitate our testing before that, we can certainly look into updating our testing code and test report to using OCCI 1.1 compliant APIs.
Thanks, --Jin
-----Original Message----- From: Edmonds, AndrewX [mailto:andrewx.edmonds@intel.com] Sent: Tuesday, May 03, 2011 7:53 PM To: Sill, Alan; Tong, Jin Cc: Ralf Nyren; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Alexander Papaspyrou; Alexis Richardson Subject: RE: OCCI test server
Since this time last year SLA@SOI has had an OCCI interface on top of a testbed (approx 12 physical nodes, associated storage and OS templates, and live demo'ed at OGF30). That access was via OCCI v1.0. Currently we're moving across to OCCI v1.1 and a large number of improvements to enable better comprehension of SLAs and related QoS and as a result the testbed is not so stable. It is certainly a possibility that we here in SLA@SOI could provide access to the testbed facility here once thing are fully deployed (note this will be sooner rather than later given that SLA@SOI is officially due to finish around June).
Jin could you indicate your timelines and requirements so I can help and facilitate you? Perhaps (once back at base) I can supply you the test case scenarios implemented against our testbed.
Of course all other offers of help are appreciated ;-) Alex - UDO have some substantial infrastructure behind the OCCI interface, might there be a faster path here?
Andy
-----Original Message----- From: Sill, Alan [mailto:alan.sill@ttu.edu] Sent: Tuesday, May 03, 2011 6:49 PM To: Tong, Jin Cc: Ralf Nyren; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Edmonds, AndrewX; Alexander Papaspyrou; Alexis Richardson Subject: OCCI test server
I think Ralf's server is for interface testing only (no actual machine starting occurs?), though I could be mistaken.
Is there a test server somewhere to which we can grant Jin access for SAJACC testing?
Thanks, Alan
On May 3, 2011, at 11:05 AM, "Tong, Jin"
wrote: Ralf,
With regard to this particular OCCI endpoint and the sample curl commands you sent earlier (see below):
* What is really running ("active") after the curl command to do the HTTP POST? I didn't see the post sending over parameters to identify network, storage/disk -- bootbable images, etc. Is there some default OS image that is being spun up? * Is there anyway to connect to the VM spun up? The HTTP GET command to the compute resource I spun up doesn't include any network access (such as IP) information. * Does this particular implementation of this site support customization of the VMs, such as seeding the VM with a public key for an user account that needs ssh access later?
Thanks, --Jin
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Saturday, April 02, 2011 3:43 PM To: Alan Sill; Sill, Alan Cc: Tong, Jin; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Edmonds, AndrewX Subject: Re: Current drafts and comments on "pre-9th" draft for Standards Roadmap document; meeting schedule
On Thu, 31 Mar 2011 22:35:17 +0200, Alan Sill
wrote: Note one useful thing would be to see how many of the identified SAJACC use cases can easily be checked off using this example instance:
The following use cases regarding VM management are easy enough to check using the example instance:
3.7 VM Control: Allocate VM Instance
# Allocate a VM instance like this: curl -X POST -H 'content-type: text/occi' -H 'category: compute; scheme=http://schemas.ogf.org/occi/infrastructure#' -H 'x-occi-attribute:
occi.compute.memory=3.0, occi.compute.cores=4' http://www.nyren.net/api/
# Copy paste the resource instance URL returned by the above command into
the below command to view the new VM instance: curl -X GET http://www.nyren.net/api/compute/xxxx
3.8 VM Control: Manage Virtual Machine Instance State
# Activate the VM by triggering the "start" action (the URL is found in the Link header returned by the previous command) curl -X POST -H 'content-type: text/occi' -H 'category: start; scheme=http://schemas.ogf.org/occi/infrastructure/compute/action#' http://www.nyren.net/api/compute/xxxx?action=start
# Repeat the GET request to see that the VM state now has changed from "inactive" to "active"
3.9 Query Cloud-Provider Capabilities and Capacities
# You can see the capabilities in terms of resource types supported at the
query interface curl -X GET http://www.nyren.net/api/-/
3.4 Copy Data Objects Into a Cloud 3.5 Copy Data Objects Out of a Cloud 3.6 Erase Data Objects In a Cloud
You can upload/download data by using OCCI Actions. There is a proposed solution currently implemented in the occi-py library but last I heard it
will be released as an extension to the 1.1 release of the OCCI spec. Unfortunately the "dummy" backend of the demo instance does not allow for
a demonstration of this feature right now.
Regarding the remaining use cases I would say that OCCI as a Protocol could handle most of them easily enough. The challenge is the service provider's implementation of the backend functionality rather than the transfer of information using OCCI.
regards, Ralf
Hi Jin, unfortunately, we don't have a OCCI 1.1 compliant endpoint; the fixes that have been incorporated into the errata haven't trickled down to the code base. I think, however, that Ralf has an endpoint, and Thijs might also be able to help you out. Best, Alexander Am 19.09.2011 um 10:18 schrieb Alan Sill:
I'd like to pick up on this request from Jin. I believe Alexander had offered access to an instance of something testable at TUDO - any others?
In general, I would like to request help working through the test cases documented for NIST SAJACC at
http://collaborate.nist.gov/twiki-cloud-computing/bin/view/CloudComputing/SA...
under "Working Documents and Artifacts"
Note they have downloadable example code for demonstrations with other standards - see last item on that list!
Alan
Begin forwarded message:
From: "Tong, Jin"
Date: May 4, 2011 4:43:12 PM GMT+02:00 To: "Edmonds, AndrewX" , "Sill, Alan" Cc: Ralf Nyren , "Hogan, Michael D." , "Sokol, Annie W." , "Liu, Fang" , "Badger, Mark Lee" , Thijs Metsch , Alexander Papaspyrou , Alexis Richardson Subject: RE: OCCI test server Andy,
I just replied Alan's message and copied to occi-wg mailing list to give a little background of our testing work. In terms of timing, the next major check point is September/October this year. If we can get to an OCCI endpoint that can actually facilitate our testing before that, we can certainly look into updating our testing code and test report to using OCCI 1.1 compliant APIs.
Thanks, --Jin
-----Original Message----- From: Edmonds, AndrewX [mailto:andrewx.edmonds@intel.com] Sent: Tuesday, May 03, 2011 7:53 PM To: Sill, Alan; Tong, Jin Cc: Ralf Nyren; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Alexander Papaspyrou; Alexis Richardson Subject: RE: OCCI test server
Since this time last year SLA@SOI has had an OCCI interface on top of a testbed (approx 12 physical nodes, associated storage and OS templates, and live demo'ed at OGF30). That access was via OCCI v1.0. Currently we're moving across to OCCI v1.1 and a large number of improvements to enable better comprehension of SLAs and related QoS and as a result the testbed is not so stable. It is certainly a possibility that we here in SLA@SOI could provide access to the testbed facility here once thing are fully deployed (note this will be sooner rather than later given that SLA@SOI is officially due to finish around June).
Jin could you indicate your timelines and requirements so I can help and facilitate you? Perhaps (once back at base) I can supply you the test case scenarios implemented against our testbed.
Of course all other offers of help are appreciated ;-) Alex - UDO have some substantial infrastructure behind the OCCI interface, might there be a faster path here?
Andy
-----Original Message----- From: Sill, Alan [mailto:alan.sill@ttu.edu] Sent: Tuesday, May 03, 2011 6:49 PM To: Tong, Jin Cc: Ralf Nyren; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Edmonds, AndrewX; Alexander Papaspyrou; Alexis Richardson Subject: OCCI test server
I think Ralf's server is for interface testing only (no actual machine starting occurs?), though I could be mistaken.
Is there a test server somewhere to which we can grant Jin access for SAJACC testing?
Thanks, Alan
On May 3, 2011, at 11:05 AM, "Tong, Jin"
wrote: Ralf,
With regard to this particular OCCI endpoint and the sample curl commands you sent earlier (see below):
* What is really running ("active") after the curl command to do the HTTP POST? I didn't see the post sending over parameters to identify network, storage/disk -- bootbable images, etc. Is there some default OS image that is being spun up? * Is there anyway to connect to the VM spun up? The HTTP GET command to the compute resource I spun up doesn't include any network access (such as IP) information. * Does this particular implementation of this site support customization of the VMs, such as seeding the VM with a public key for an user account that needs ssh access later?
Thanks, --Jin
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Saturday, April 02, 2011 3:43 PM To: Alan Sill; Sill, Alan Cc: Tong, Jin; Hogan, Michael D.; Sokol, Annie W.; Liu, Fang; Badger, Mark Lee; Thijs Metsch; Edmonds, AndrewX Subject: Re: Current drafts and comments on "pre-9th" draft for Standards Roadmap document; meeting schedule
On Thu, 31 Mar 2011 22:35:17 +0200, Alan Sill
wrote: Note one useful thing would be to see how many of the identified SAJACC use cases can easily be checked off using this example instance:
The following use cases regarding VM management are easy enough to check using the example instance:
3.7 VM Control: Allocate VM Instance
# Allocate a VM instance like this: curl -X POST -H 'content-type: text/occi' -H 'category: compute; scheme=http://schemas.ogf.org/occi/infrastructure#' -H 'x-occi-attribute:
occi.compute.memory=3.0, occi.compute.cores=4' http://www.nyren.net/api/
# Copy paste the resource instance URL returned by the above command into
the below command to view the new VM instance: curl -X GET http://www.nyren.net/api/compute/xxxx
3.8 VM Control: Manage Virtual Machine Instance State
# Activate the VM by triggering the "start" action (the URL is found in the Link header returned by the previous command) curl -X POST -H 'content-type: text/occi' -H 'category: start; scheme=http://schemas.ogf.org/occi/infrastructure/compute/action#' http://www.nyren.net/api/compute/xxxx?action=start
# Repeat the GET request to see that the VM state now has changed from "inactive" to "active"
3.9 Query Cloud-Provider Capabilities and Capacities
# You can see the capabilities in terms of resource types supported at the
query interface curl -X GET http://www.nyren.net/api/-/
3.4 Copy Data Objects Into a Cloud 3.5 Copy Data Objects Out of a Cloud 3.6 Erase Data Objects In a Cloud
You can upload/download data by using OCCI Actions. There is a proposed solution currently implemented in the occi-py library but last I heard it
will be released as an extension to the 1.1 release of the OCCI spec. Unfortunately the "dummy" backend of the demo instance does not allow for
a demonstration of this feature right now.
Regarding the remaining use cases I would say that OCCI as a Protocol could handle most of them easily enough. The challenge is the service provider's implementation of the backend functionality rather than the transfer of information using OCCI.
regards, Ralf
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de
participants (2)
-
Alan Sill
-
alexander.papaspyrou@tu-dortmund.de