Open Stack

On 23 May 2014 10:34, Salvatore Orlando <sorlando at nicira.com> wrote:
> As most of you probably know already, this is one of the topics discussed
> during the Juno summit [1].
> I would like to kick off the discussion in order to move towards a concrete
> design.
>
> Preamble: Considering the meat that's already on the plate for Juno, I'm not
> advocating that whatever comes out of this discussion should be put on the
> Juno roadmap. However, preparation (or yak shaving) activities that should
> be identified as pre-requisite might happen during the Juno time frame
> assuming that they won't interfere with other critical or high priority
> activities.
> This is also a very long post; the TL;DR summary is that I would like to
> explore task-oriented communication with the backend and how it should be
> reflected in the API - gauging how the community feels about this, and
> collecting feedback regarding design, constructs, and related
> tools/techniques/technologies.

Hi, thanks for writing this up.

A few thoughts:

 - if there can be only one task on a resource at a time, you're
essentially forcing all other clients to poll for task completion
before coming back to do *their* change. Its kindof a pathological
edge case of no in-flight-conflicts :).
 - Please please please don't embed polling into the design - use
webhooks or something similar so that each client (be that Nova,
Ironic, Horizon or what-have-you - can get a push response when the
thing they want to happen has happened).
 - I'd think very very carefully about whether you're actually
modelling /tasks/ or whether tasks are the implementation and really
the core issue is modelling the desired vs obtained resource state
 - Ironic has a debate going on right now about very much the same
problem - the latency involved in some API tasks, and whether the API
should return when complete, or when the work his guaranteed to start,
or even immediately and maybe the work isn't guaranteed to start.

My feeling is that we need to balance ease and correctness of
implementation, ease (and efficiency/correctness) of use, and
robustness - an entirely non-blocking API might end up being the
polling nightmare of nightmares if not done carefully, for instance.

-Rob