Re: [occi-wg] Draft of OCCI 1.1 profile for VM templates/flavours
Hi, Hmm. mostly OK but I think we have to look ahead. HTTP/2 will certainly be through the publication pipeline by the time that OCCI 1.2 makes it to publications tatus for review. Some up to date references: https://http2.github.io http://www.ietf.org/blog/2015/02/http2-approved/ http://www.rfc-editor.org/queue2.html#draft-ietf-httpbis-http2 You may also want to look through the FAQ items: https://http2.github.io/faq/ I think that all that is necessary right now is to take note (as has been stated before by members of this group) that HTTP/2 does not affect the design or basic use of the OCCI specs, and initiate a study to explore the practical use of HTTP/2 with OCCI (1.1. or 1.2). For the latter, please join the “Cloud Interoperability testbed” project on Chameleon (http://chameleoncloud.org) (project FG-176) and/or the “cacnetworking” project on CloudLab (http://cloudlab.us) if your project has something to do with networking or would be a better fit there. These projects are new, managed by me, and approved specifically to do testing in multiple cloud software environments for interoperability and standards-based software. I would like to encourage the entire OCCI working group, and any other group member of standards efforts in other organizations to join. Accounts are free, the projects are new, and the door is open to participation from this group. Alan On Mar 17, 2015, at 11:53 AM, Michel Drescher <michel.drescher@egi.eu<mailto:michel.drescher@egi.eu>> wrote: Hi Boris, all, There are two major reasons for being specific about HTTP/1.1 as follows: 1) HTTP/2 is in the making, that is true - but there is no referenceable RFC out there. 2) OCCI Restful makes itself a specific reference to HTTP/1.1 (c.f. GFD.185 reference no. 5) and its serialisation mechanisms. Regarding the compatibility with HTTP/2, or whether HTTP/2 implementations would be considered eligible to claim conformance. Both OCCI Restful as well as the profile make references to the HTTP header rendering mechanism defined in HTTP 1.1. But neither imposes any conformance requirement that the HTTP/1.1 protocol itself must be used. Furthermore, the only situation in which this discussion applies is where both client and server support HTTP/2 - in all other situations, any attempt to initiate a protocol upgrade to HTTP/2 will fail and communications remain at HTTP/1.1 level. Having said that, HTTP/2 does impose any restrictions or changes on HTTP header rendering, HTTP messages etc. Hence conformity with both OCCI Rendering and the profile are considered as achieved from my point of view. Cheers, Michel P.S.: A corollary implication from this is IMHO that there is no need to upgrade any existing specification, even in the event of HTTP/2 obsoleting HTTP/1.1 (which it states as not being the goal). On 17 March 2015 at 15:18, Boris Parak <xparak@mail.muni.cz<mailto:xparak@mail.muni.cz>> wrote: On Tue, Mar 17, 2015 at 3:22 PM, Sill, Alan <alan.sill@ttu.edu<mailto:alan.sill@ttu.edu>> wrote:
Any particular reason to specify exactly HTTP/1.1? I think that there are many advantages to using HTTP/2 for header compression, possibility to use multiplexed single-connection communications, binary representation, server push responses, etc. It’s backwards compatible so I think we need to allow for more generality.
Good point. There is no specific reason to use HTTP/1.1, aside from it being referenced in OCCI 1.1 HTTP Rendering spec [1]. If using HTTP/2 doesn't break anything with regard to OCCI 1.1, we can use it. Otherwise it will have to be included in an updated version of the profile for OCCI 1.2. In any case, it would be an encouragement, not a requirement (for practical reasons). Michel, is this correct? [1] https://www.ogf.org/documents/GFD.185.pdf
I started a discussion on tis on another thread, but am holding off asking for anything specific until we can try it out.
Alan
Boris
On Mar 17, 2015, at 7:21 AM, Boris Parak <xparak@mail.muni.cz<mailto:xparak@mail.muni.cz>> wrote:
Hello everyone,
I have here, for your consideration, one of the first "formal" outputs of EGI FedCloud's work with OCCI -- The OCCI Resource Template Profile. We would very much like to hear your opinions, comments and/or suggestions.
After this (brief, hopefully) internal discussion phase, we would like to push for a public comment phase as soon as possible.
Thank you!
Cheers, Boris --- CESNET / EGI FedCloud <OCCI Resource template profile v6.docx><OCCI Resource template profile v6.pdf><OCCI Resource template profile v6.rtf>_______________________________________________ occi-wg mailing list occi-wg@ogf.org<mailto:occi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/occi-wg
-- Stichting European Grid Initiative (EGI.eu<http://EGI.eu>) http://www.egi.eu<http://www.egi.eu/> Mobile:+31 (0)6 303 726 55 Skype: michel.drescher.egi Entropy isn't what it used to be...
Let me be clear on this: These two new US NSF projects, Chameleon and CloudLab, are specifically designed for “testbed as a service”, a la the previous and now completed FutureGrid project. They are general testbed implementation frameworks that allow you to install and configure any software for which you have licenses (commercial or open source), and are specifically designed to allow short-term tests of such software. Easy access is available and the environment is intended to allow repeatable, reproducible instantiation for computer science or other repeatable test projects. The projects are new and templates are not available for all possible software. OpenStack is easy and in the past, we also had other software, such as Eucalyptus etc. also available on FutureGrid, so I imagine templates will become available soon for other infrastructure software. You can create a template yourself for anything you want, or work with the available templates to add interfaces for example to OpenStack. I think a short-term low hanging fruit use might be to add occi-os to the existing OpenStack REST and EC2 interfaces for Alamo on Chameleon, for example. Other projects are possible. The utility of this is that you get to instantiate your own whole cloud environments from scratch on this infrastructure, including any special changes or adaptions you would like to try out, and run them as you would a batch job for interoperability and/or performance testing purposes. This frees you up from having to depend on the versions of the software that are supported on running production interfaces, and will hopefully be useful for testing. I encourage the whole group to sign up. Pleas do so! The only thing that I ask in return is that you agree to provide at the end of the project some time in the future a brief summary of what you have learned in using the testbed. Alan On Mar 17, 2015, at 12:16 PM, Sill, Alan <alan.sill@ttu.edu<mailto:alan.sill@ttu.edu>> wrote: I think that all that is necessary right now is to take note (as has been stated before by members of this group) that HTTP/2 does not affect the design or basic use of the OCCI specs, and initiate a study to explore the practical use of HTTP/2 with OCCI (1.1. or 1.2). For the latter, please join the “Cloud Interoperability testbed” project on Chameleon (http://chameleoncloud.org<http://chameleoncloud.org/>) (project FG-176) and/or the “cacnetworking” project on CloudLab (http://cloudlab.us<http://cloudlab.us/>) if your project has something to do with networking or would be a better fit there. These projects are new, managed by me, and approved specifically to do testing in multiple cloud software environments for interoperability and standards-based software. I would like to encourage the entire OCCI working group, and any other group member of standards efforts in other organizations to join. Accounts are free, the projects are new, and the door is open to participation from this group.
participants (1)
-
Sill, Alan