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@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev