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

[Andy Edmonds]

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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20140902/52aa949a/attachment.html>