[occi-wg] Fwd: Feedback, suggestions and questions from EGI FedCloud

[Boris Parak]

Hi Andy,

thank you for a quick response :-) Comments below.

On Tue, Sep 2, 2014 at 1:15 PM, Andy Edmonds <andrew.edmonds at 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 at 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 at ogf.org
>> https://www.ogf.org/mailman/listinfo/occi-wg
>
>