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