Draft of OCCI 1.1 profile for VM templates/flavours
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
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. I started a discussion on tis on another thread, but am holding off asking for anything specific until we can try it out. Alan
On Mar 17, 2015, at 7:21 AM, Boris Parak <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 https://www.ogf.org/mailman/listinfo/occi-wg
On Tue, Mar 17, 2015 at 3:22 PM, Sill, Alan <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> 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 https://www.ogf.org/mailman/listinfo/occi-wg
Hello Boris, everybody, We are working on a Model-Driven Engineering approach for OCCI in the context of the OCCIware project (see http://www.occiware.org). One output of this project will be OCCIware Studio, a set of Eclipse plugins for OCCI. OCCIware Studio will be helpful for designers of OCCI extensions, like you. I have modeled your proposal with our current studio prototype. With this studio, I have validated your extension, i.e., your extension does not break any semantics constraint of our OCCI metamodel. Then, the OCCIware studio allows us to generate both a diagram and a Textile documentation for your OCCI extension. See both attached files. OCCIware Studio is currently based on OCCI Core 1.1 errata version, which is very similar to OCCI Core 1.2. In the future, OCCIware Studio will provide a lot of other features, like a concrete textual language for OCCI, generations for existing OCCI runtime frameworks, etc. Your feature proposals are welcome. Philippe Merle Scientific and technical leader of OCCIware project Inria researcher Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hello Philippe, On Wed, Mar 18, 2015 at 6:26 AM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris, everybody,
We are working on a Model-Driven Engineering approach for OCCI in the context of the OCCIware project (see http://www.occiware.org). One output of this project will be OCCIware Studio, a set of Eclipse plugins for OCCI. OCCIware Studio will be helpful for designers of OCCI extensions, like you.
sounds interesting, how far along are you with the development of OCCIware Studio?
I have modeled your proposal with our current studio prototype. With this studio, I have validated your extension, i.e., your extension does not break any semantics constraint of our OCCI metamodel. Then, the OCCIware studio allows us to generate both a diagram and a Textile documentation for your OCCI extension. See both attached files.
Thank you!
OCCIware Studio is currently based on OCCI Core 1.1 errata version, which is very similar to OCCI Core 1.2. In the future, OCCIware Studio will provide a lot of other features, like a concrete textual language for OCCI, generations for existing OCCI runtime frameworks, etc. Your feature proposals are welcome.
Philippe Merle Scientific and technical leader of OCCIware project Inria researcher
Cheers, Boris
Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Boris, everybody, Le 18/03/15 11:17, Boris Parak a écrit :
Hello Philippe,
On Wed, Mar 18, 2015 at 6:26 AM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris, everybody,
We are working on a Model-Driven Engineering approach for OCCI in the context of the OCCIware project (see http://www.occiware.org). One output of this project will be OCCIware Studio, a set of Eclipse plugins for OCCI. OCCIware Studio will be helpful for designers of OCCI extensions, like you. sounds interesting, how far along are you with the development of OCCIware Studio?
Our OCCIware funded project started in December 2014 for 3 years. Three months later, we already have a prototype of the OCCIware Studio, but it is not yet a product. The prototype is already usable but limited, few documentation, etc. I hope a first release should be available during this summer. OCCIware Studio is an open source software and early users/contributors are welcome. best regards Philippe
I have modeled your proposal with our current studio prototype. With this studio, I have validated your extension, i.e., your extension does not break any semantics constraint of our OCCI metamodel. Then, the OCCIware studio allows us to generate both a diagram and a Textile documentation for your OCCI extension. See both attached files. Thank you!
OCCIware Studio is currently based on OCCI Core 1.1 errata version, which is very similar to OCCI Core 1.2. In the future, OCCIware Studio will provide a lot of other features, like a concrete textual language for OCCI, generations for existing OCCI runtime frameworks, etc. Your feature proposals are welcome.
Philippe Merle Scientific and technical leader of OCCIware project Inria researcher Cheers, Boris
Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hello Boris, I have one comment on your OCCI Compute Resource Templates. This specification does not explicitly define in which category (Kind or Mixin) the attribute eu.egi.fedcloud.occi.compute.ephemeral is defined. It could be defined in each of the six mixins or as I did it could be defined in an ephemeral mixin inherited by the six mixins. I prefer the second solution, which factorizes common elements of the six mixins. A+ Philippe Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hello Philippe, On Thu, Mar 19, 2015 at 1:00 AM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris,
I have one comment on your OCCI Compute Resource Templates. This specification does not explicitly define in which category (Kind or Mixin) the attribute eu.egi.fedcloud.occi.compute.ephemeral is defined. It could be defined in each of the six mixins or as I did it could be defined in an ephemeral mixin inherited by the six mixins. I prefer the second solution, which factorizes common elements of the six mixins.
it might not be explicitly mentioned there, but we adopted the first approach you mentioned. We had a few reasons for doing that: 1.) the whole point of that attribute is setting a default value different for each of those six mixins ; therefore it would have to be "included" in all of them anyway ... and in a separate additional mixin if we adopted the second approach (6 vs. 7 mixins with that attribute) 2.) we do not use OCCI for modeling purposes, features such as attribute inheritance from related mixins are not implemented ; this means that defining an attribute in one mixin and setting a default value for that attribute in a different related mixin wouldn't work 3.) this is all about practical applications for OCCI Infrastructure ; we made it as simple as possible If that makes any sense to you ...
A+ Philippe
Cheers, Boris
Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hello Boris, Le 19/03/15 10:32, Boris Parak a écrit :
Hello Philippe,
On Thu, Mar 19, 2015 at 1:00 AM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris,
I have one comment on your OCCI Compute Resource Templates. This specification does not explicitly define in which category (Kind or Mixin) the attribute eu.egi.fedcloud.occi.compute.ephemeral is defined. It could be defined in each of the six mixins or as I did it could be defined in an ephemeral mixin inherited by the six mixins. I prefer the second solution, which factorizes common elements of the six mixins. it might not be explicitly mentioned there, but we adopted the first approach you mentioned. We had a few reasons for doing that:
1.) the whole point of that attribute is setting a default value different for each of those six mixins ; therefore it would have to be "included" in all of them anyway ... and in a separate additional mixin if we adopted the second approach (6 vs. 7 mixins with that attribute)
ok. I just pointed a drawback in the proposed specification. This specification defines an attribute but does not define in which category(ies) it is defined. So perhaps you could add a sentence to say 'This attribute is defined in each of the following six mixins.'
2.) we do not use OCCI for modeling purposes,
You should.
features such as attribute inheritance from related mixins are not implemented ;
Do you want to say that attribute inheritance from related mixins are not implemented in the specific OCCI runtime you use. The OCCI core specification allows this.
this means that defining an attribute in one mixin and setting a default value for that attribute in a different related mixin wouldn't work
in the specific OCCI runtime you use, not in OCCI in general.
3.) this is all about practical applications for OCCI Infrastructure ; we made it as simple as possible
If that makes any sense to you ...
In OCCIware we have industrial partners that do practical applications of OCCI. OCCIware is not just a pure research project. So this makes sense for me ;-) A+ Philippe
A+ Philippe Cheers, Boris
Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
On Thu, Mar 19, 2015 at 5:17 PM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris,
Le 19/03/15 10:32, Boris Parak a écrit :
Hello Philippe,
On Thu, Mar 19, 2015 at 1:00 AM, Philippe Merle <philippe.merle@inria.fr> wrote:
Hello Boris,
I have one comment on your OCCI Compute Resource Templates. This specification does not explicitly define in which category (Kind or Mixin) the attribute eu.egi.fedcloud.occi.compute.ephemeral is defined. It could be defined in each of the six mixins or as I did it could be defined in an ephemeral mixin inherited by the six mixins. I prefer the second solution, which factorizes common elements of the six mixins.
it might not be explicitly mentioned there, but we adopted the first approach you mentioned. We had a few reasons for doing that:
1.) the whole point of that attribute is setting a default value different for each of those six mixins ; therefore it would have to be "included" in all of them anyway ... and in a separate additional mixin if we adopted the second approach (6 vs. 7 mixins with that attribute)
ok. I just pointed a drawback in the proposed specification. This specification defines an attribute but does not define in which category(ies) it is defined. So perhaps you could add a sentence to say 'This attribute is defined in each of the following six mixins.'
Good point. Will do.
2.) we do not use OCCI for modeling purposes,
You should.
I know :-)
features such as attribute inheritance from related mixins are not implemented ;
Do you want to say that
attribute inheritance from related mixins are not implemented
in the specific OCCI runtime you use.
The OCCI core specification allows this.
Yes, specific runtime(s)/implementation(s).
this means that defining an attribute in one mixin and setting a default value for that attribute in a different related mixin wouldn't work
in the specific OCCI runtime you use, not in OCCI in general.
Exactly.
3.) this is all about practical applications for OCCI Infrastructure ; we made it as simple as possible
If that makes any sense to you ...
In OCCIware we have industrial partners that do practical applications of OCCI. OCCIware is not just a pure research project. So this makes sense for me ;-)
Thank you for your feedback!
A+ Philippe
Cheers, Boris
A+ Philippe
Cheers, Boris
Le 17/03/15 13:21, Boris Parak a écrit :
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-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
participants (3)
-
Boris Parak -
Philippe Merle -
Sill, Alan