Open Stack

On 08/05/2013 04:34 AM, Brian Rosmaita wrote:
> Well, it's tomorrow as I write this, maybe it's today as you read
> this.  Anyway:
> 
> - asynchronous worker meeting Tuesday 6 Aug 2013 14:00 UTC in
> #openstack-glance
> 
> - the etherpad
> https://etherpad.openstack.org/havana-glance-requirements was updated
> after the last meeting
> 
> - if you missed the last meeting, the log is at
> https://etherpad.openstack.org/havana-glance-requirements-meeting-02-aug
>
> 
_______________________________________________
> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

All,

I am very interested in this work but I cannot make the meeting because
it is at 4am my time and I am still sitting at my laptop as I stare down
the barrel of midnight.

I first want to thank Brain et al for the great work.  The wiki pages
they have are well thought out and defined.  I am very interested in
seeing that this work is successfully completed because I feel it is a
key part in making Glance a significantly more useful service.

When discussing this with the community in the past I have fallen into
the trap of getting lost in implementation details and thereby confused
the focus of the efforts first steps.  I am slightly concerned that this
meeting could take a turn into too much concern for details that are
better covered later (for example: how a task is implemented, what does
the plug in interface look like, will these tasks be scheduled via
messaging, etc).  Thus I thought I would send out what deliverables I
now hope will come from this meeting.  Here they are:

A near complete user facing REST API
 -- Brian has this well described in the previously linked wiki pages,
    all that is needed is a y or n.  I vote y.

An agreed upon (initial/direction setting) set of use cases that this
API can handle.  As an example:

    1) validate an incoming image as bootable
    2) check an incoming image for a license
    3) convert an image from one format to another (ex: raw->qcow2)
    4) extract size information (image size vs storage size)
    5) information injection/scrubbing from the image
    6) perform an operator defined processor time intensive operation
       upon an image before allow it to be a) registered as a valid
       image location, b) downloaded.

A set of requirements for that REST API
-- ex:

   1) The lifespan of the client connection can be shorter than that of
      the workload.
   2) An image can be deleted without deleting the task associated with
      it (just an example!)
   3) multiple tasks can be performed on a single image safely at the
      same time
   4) A single task request is guaranteed to only happen once.  Two
      threads of execution will never iterate over the same byte,
      neither at the same time nor in serial (again, an example and one
      that admittedly may be beyond the scope of the API discussion).
        -- on this point I am concerned with cases where a task fails
           and is restarted.  Do we guarantee that all tasks failed as
           well and thus can safely be restarted?

Thanks!

John