Fwd: Feedback, suggestions and questions from EGI FedCloud
Hello everyone, since OGF42 in London is rapidly approaching, I would like to start a discussion ... to get a running start. The following issues/questions/suggestions are mostly based on our practical experience with OCCI in EGI FedCloud. Feel free to comment (or ignore me) :-) Items are ordered by importance. 1.) OS and resource templates (mixins -> resources) While moving to production in the last few months, we've found that os_tpl and resource_tpl mixins do not provide enough information about the "resources" (images and flavors in OpenStack, virtual machine templates in OpenNebula etc.) they represent. I know that this is a quite common approach adopted for instance by Amazon in AWS EC2 but in some environments we need to be able to "attach" more information to these concepts. In general, the following information is required: os_tpl: external appliance ID resource_tpl: number of cores, amount of memory, amount/type of storage, included optional block devices Term and scheme of a mixin simply do not provide a strong-enough mechanism. At the moment, we have to use external mapping mechanisms (an LDAP-based information system) and therefore duplicate information in several places. It would be very helpful to be able to attach arbitrary attributes to os_tpls and resource_tpls. Perhaps specify them as resources instead of mixins and use linking to attach them to compute instances (inline, on creation)? Do you have any other ideas? 2.) Advanced networking concepts This will be very brief and vague. Do you have any plans to represent various networking elements (routers, switches, gateways, etc.) in the standard? Or, in general, extend the infrastructure network specification to include tools for specifying complex network setups? 3.) Available resources Are there any plans for including concepts and querying mechanisms for getting the amount of currently available resources? Is this outside of the scope of OCCI or the commonly accepted concept of the "cloud"? How would you handle this? Would it fall into OCCI Monitoring? I'm thinking in terms of "How many 'resource_tpl#small' computes can I launch right now?". 4.) Asynchronous/queued actions Is there a recommended approach to asynchronous or queued actions (not necessarily OCCI "actions")? This goes mostly to implementation. Should I block until the action is finished? Can I respond with HTTP 202 Accepted (for example, it doesn't have to be HTTP) and process it later? In that case, shouldn't I provide a link where the user can get the current status of his action? Did anyone deal with a similar problem? Is there a solution you would prefer, standard-wise? 5.) Updating mixins When using a partial update to add/replace a mixin (or mixins) on a compute instance (as an example), how do I know which mixin to replace? Or whether to replace it or add a new one? Shouldn't OCCI specify which mixin types can be included only once per instance? Or define some "replacing" rules? I'm looking at [1], to give you a practical reference. [1] https://wiki.openstack.org/wiki/Occi#Scale_Up_a_VM Any feedback will be greatly appreciated. We can, of course, continue the conversation next week in London. Hope to see you all there. Thanks! Cheers, Boris Parak --- On behalf of EGI FedCloud, CESNET and the rOCCI dev team
Hey Boris, 1. Why not extend as allowed by core and as shown in the resource template section of the infrastructure spec? 2. I think currently the networking section of the infrastructure spec is sufficient (switch: don't set a gateway address, router: set a gateway address; a gateway is just another upstream router or switch). Of course if this is not sufficient specialise the resource or extend by mixin. 3. No. It's something that has popped up in the past but decided not to be pursued. Assumption is that resources offered by a provider is infinite unless a server side error is raised. 4. currently in the OpenStack implementation, this is handled by initiating the VM instantiation request, updating the status (initially set to inactive) and returning as soon as is possible to the client. After that the client can query until the compute resource's state is 'active'. 5. the 'applies' core model attribute from the core spec covers this. You cannot update mixins only add and remove. So in fact the OpenStack example is non-compliant (likely my bad!). HTH, Andy Andy Edmonds Æ Senior Researcher, ICCLab Institute of Information Technology Zürich University of Applied Sciences http://www.cloudcomp.ch, @dizz On 1 September 2014 17:33, Boris Parak <xparak@mail.muni.cz> wrote:
Hello everyone,
since OGF42 in London is rapidly approaching, I would like to start a discussion ... to get a running start. The following issues/questions/suggestions are mostly based on our practical experience with OCCI in EGI FedCloud. Feel free to comment (or ignore me) :-)
Items are ordered by importance.
1.) OS and resource templates (mixins -> resources)
While moving to production in the last few months, we've found that os_tpl and resource_tpl mixins do not provide enough information about the "resources" (images and flavors in OpenStack, virtual machine templates in OpenNebula etc.) they represent. I know that this is a quite common approach adopted for instance by Amazon in AWS EC2 but in some environments we need to be able to "attach" more information to these concepts. In general, the following information is required:
os_tpl: external appliance ID
resource_tpl: number of cores, amount of memory, amount/type of storage, included optional block devices
Term and scheme of a mixin simply do not provide a strong-enough mechanism. At the moment, we have to use external mapping mechanisms (an LDAP-based information system) and therefore duplicate information in several places.
It would be very helpful to be able to attach arbitrary attributes to os_tpls and resource_tpls. Perhaps specify them as resources instead of mixins and use linking to attach them to compute instances (inline, on creation)?
Do you have any other ideas?
2.) Advanced networking concepts
This will be very brief and vague. Do you have any plans to represent various networking elements (routers, switches, gateways, etc.) in the standard? Or, in general, extend the infrastructure network specification to include tools for specifying complex network setups?
3.) Available resources
Are there any plans for including concepts and querying mechanisms for getting the amount of currently available resources? Is this outside of the scope of OCCI or the commonly accepted concept of the "cloud"? How would you handle this? Would it fall into OCCI Monitoring?
I'm thinking in terms of "How many 'resource_tpl#small' computes can I launch right now?".
4.) Asynchronous/queued actions
Is there a recommended approach to asynchronous or queued actions (not necessarily OCCI "actions")? This goes mostly to implementation. Should I block until the action is finished? Can I respond with HTTP 202 Accepted (for example, it doesn't have to be HTTP) and process it later? In that case, shouldn't I provide a link where the user can get the current status of his action? Did anyone deal with a similar problem? Is there a solution you would prefer, standard-wise?
5.) Updating mixins
When using a partial update to add/replace a mixin (or mixins) on a compute instance (as an example), how do I know which mixin to replace? Or whether to replace it or add a new one? Shouldn't OCCI specify which mixin types can be included only once per instance? Or define some "replacing" rules? I'm looking at [1], to give you a practical reference.
[1] https://wiki.openstack.org/wiki/Occi#Scale_Up_a_VM
Any feedback will be greatly appreciated. We can, of course, continue the conversation next week in London. Hope to see you all there.
Thanks!
Cheers, Boris Parak --- On behalf of EGI FedCloud, CESNET and the rOCCI dev team _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Hi Andy, thank you for a quick response :-) Comments below. On Tue, Sep 2, 2014 at 1:15 PM, Andy Edmonds <andrew.edmonds@zhaw.ch> wrote:
Hey Boris,
1. Why not extend as allowed by core and as shown in the resource template section of the infrastructure spec?
We are actually using this mechanism (internally, in the server). How would I render this information in text/occi or text/plain for the client? Mixins are defined in the model and, for the client, rendered into a response to GET /-/ (the same as kinds and actions). Is there a way to render attributes (with values) for mixins?
2. I think currently the networking section of the infrastructure spec is sufficient (switch: don't set a gateway address, router: set a gateway address; a gateway is just another upstream router or switch). Of course if this is not sufficient specialise the resource or extend by mixin.
OK, thanks.
3. No. It's something that has popped up in the past but decided not to be pursued. Assumption is that resources offered by a provider is infinite unless a server side error is raised.
Yeah, I thought as much.
4. currently in the OpenStack implementation, this is handled by initiating the VM instantiation request, updating the status (initially set to inactive) and returning as soon as is possible to the client. After that the client can query until the compute resource's state is 'active'.
And what about other actions? For example, attaching a storagelink? I guess the same would apply there ... immediately 'inactive' and after a time changed to 'active'. What about destroying a compute? What I'm asking is: Is it semantically acceptable to respond HTTP 200 OK and not HTTP 202 Accepted when the action hasn't been completed yet? How do we handle failures after the HTTP 200 OK response has been sent to the client?
5. the 'applies' core model attribute from the core spec covers this. You cannot update mixins only add and remove. So in fact the OpenStack example is non-compliant (likely my bad!).
OK, makes sense.
HTH, Andy
Thanks! Cheers, Boris
Andy Edmonds Æ Senior Researcher, ICCLab Institute of Information Technology Zürich University of Applied Sciences http://www.cloudcomp.ch, @dizz
On 1 September 2014 17:33, Boris Parak <xparak@mail.muni.cz> wrote:
Hello everyone,
since OGF42 in London is rapidly approaching, I would like to start a discussion ... to get a running start. The following issues/questions/suggestions are mostly based on our practical experience with OCCI in EGI FedCloud. Feel free to comment (or ignore me) :-)
Items are ordered by importance.
1.) OS and resource templates (mixins -> resources)
While moving to production in the last few months, we've found that os_tpl and resource_tpl mixins do not provide enough information about the "resources" (images and flavors in OpenStack, virtual machine templates in OpenNebula etc.) they represent. I know that this is a quite common approach adopted for instance by Amazon in AWS EC2 but in some environments we need to be able to "attach" more information to these concepts. In general, the following information is required:
os_tpl: external appliance ID
resource_tpl: number of cores, amount of memory, amount/type of storage, included optional block devices
Term and scheme of a mixin simply do not provide a strong-enough mechanism. At the moment, we have to use external mapping mechanisms (an LDAP-based information system) and therefore duplicate information in several places.
It would be very helpful to be able to attach arbitrary attributes to os_tpls and resource_tpls. Perhaps specify them as resources instead of mixins and use linking to attach them to compute instances (inline, on creation)?
Do you have any other ideas?
2.) Advanced networking concepts
This will be very brief and vague. Do you have any plans to represent various networking elements (routers, switches, gateways, etc.) in the standard? Or, in general, extend the infrastructure network specification to include tools for specifying complex network setups?
3.) Available resources
Are there any plans for including concepts and querying mechanisms for getting the amount of currently available resources? Is this outside of the scope of OCCI or the commonly accepted concept of the "cloud"? How would you handle this? Would it fall into OCCI Monitoring?
I'm thinking in terms of "How many 'resource_tpl#small' computes can I launch right now?".
4.) Asynchronous/queued actions
Is there a recommended approach to asynchronous or queued actions (not necessarily OCCI "actions")? This goes mostly to implementation. Should I block until the action is finished? Can I respond with HTTP 202 Accepted (for example, it doesn't have to be HTTP) and process it later? In that case, shouldn't I provide a link where the user can get the current status of his action? Did anyone deal with a similar problem? Is there a solution you would prefer, standard-wise?
5.) Updating mixins
When using a partial update to add/replace a mixin (or mixins) on a compute instance (as an example), how do I know which mixin to replace? Or whether to replace it or add a new one? Shouldn't OCCI specify which mixin types can be included only once per instance? Or define some "replacing" rules? I'm looking at [1], to give you a practical reference.
[1] https://wiki.openstack.org/wiki/Occi#Scale_Up_a_VM
Any feedback will be greatly appreciated. We can, of course, continue the conversation next week in London. Hope to see you all there.
Thanks!
Cheers, Boris Parak --- On behalf of EGI FedCloud, CESNET and the rOCCI dev team _______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
Why not a 1xx? SIP-like (ringing...) 2014-09-02 14:29 GMT+02:00 Papaspyrou, Alexander < papaspyrou@adesso-mobile.de>:
Hi Boris,
comments below.
Cheers, Alexander
-- *adesso mobile solutions GmbH* Dr. Alexander Papaspyrou Chief Architect
Freie-Vogel-Str. 391 | 44269 Dortmund T +49 231 930 66480 | F +49 231 930 9317 | M +49 172 209 4739 Mail: papaspyrou@adesso-mobile.de | Web: www.adesso-mobile.de | Mobil-Web: mobil.adesso-mobile.de
Vertretungsberechtigte Geschäftsführer: Dr. Josef Brewing, Frank Dobelmann Registergericht: Amtsgericht Dortmund Registernummer: HRB 13763 Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE201541832
Am 02.09.2014 um 14:02 schrieb Boris Parak <xparak@mail.muni.cz>:
What I'm asking is: Is it semantically acceptable to respond HTTP 200 OK and not HTTP 202 Accepted when the action hasn't been completed yet? How do we handle failures after the HTTP 200 OK response has been sent to the client?
No, that would not be acceptable. If you get back a 200 OK for a manipulating operation, the operation should have completed. This is especially true for actions. The corner case here is that you have a long-running operation in the backend (stating 202 Accepted), which fails later; this is not handled by either OCCI or HTTP in a canonical way.
If this would affect a resource, I would expect the backend to send back the previous (unmanipulated) state of the resource on the next GET operation, or (if a new resource was supposed to created) a 404 Not Found, because it was never created in the first place.
An out-of-band status message whether (and what) failure has happened during the course of a 202 Accepted (until the operation has finished) is not something RESTful services handle nicely; usually, an operational status resource is created (which you can then poll), or a separate side channel (e.g. via Websockets) would be established.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg
-- Augusto Ciuffoletti Dipartimento di Informatica Università di Pisa 56100 - Pisa (Italy)
participants (4)
-
Andy Edmonds -
Augusto Ciuffoletti -
Boris Parak -
Papaspyrou, Alexander