Apologies for forking the thread, but there was way too much in Doug's email (and Flavio's response) and I only want to make a few points about tasks. Please read Doug's original email and Flavio's reply at some point, preferably before you read this.
I'm going to limit myself to 4 points. We'll be discussing Glance tasks during the Mitaka summit design session, so we'll be able to go into details and determine the future of tasks there. But I would like to make these points before discussion gets too far along. (1) DefCore So I see DefCore as a two-way street, in which the OpenStack projects need to be aware of what's going on with the DefCore process, and the DefCore people are paying attention to what's going on in the projects. Glance tasks are not a recent innovation, they date back at least to the Havana summit, April 15-18, 2013. There was a session on "Getting Glance Ready for Public Clouds" [1], resulting in a blueprint for "New Upload Download Workflow for Public Glance" [2], which was filed on 2013-04-22. This was pre-specs days, but there was lots of information about the design direction this was taking posted on the wiki (see [3] and [4], which contain links to most of the stuff). My point is simply that the need for tasks and the discussion around their development and structure was carried out in the open via the standard OpenStack practices, and if Glance was headed in a weird/nonstandard/deviant direction, some guidance would have been useful at that point. (I'm not implying that such guidance is not useful now, of course.) (2) Tasks as a Public API Well, that has been the whole point throughout the entire discussion. See [1]-[4]. (3) Tasks and Deployers I participated in some of the DefCore discussions around image upload that took place before the Liberty summit. It just so happened that I was on the program to give a talk about Glance tasks, and I left room for discussion about (a) whether two image upload workflows are confusing for end users, and (b) whether the flexibility of tasks (e.g., the "input" element defined as a JSON blob) is actually a problem. (You can look at the talk [5] or my slides [6] to see that I didn't pull any punches about this.) The feedback I got from the deployers present was that they weren't worried about (a), and that they liked (b) because it enabled them to make customizations easily for their particular situation. I'm not saying that there's no other way to do this -- e.g., you could do all sorts of alternative workflows and configurations in the "regular" upload process -- but the feedback I got can be summarized like this: Given the importance of a properly-functioning Glance for normal cloud operations, it is useful to have one upload/download workflow that is locked down and you don't have to worry about, and a completely different workflow that you can expose to end users and tinker with as necessary. (4) Interoperability In general, this is a worthy goal. The OpenStack cloud platform, however, is designed to handle many different deployment scenarios from small private clouds to enormous public clouds, and allowing access to the same API calls in all situations is not desirable. A small academic department, for example, may allow regular end users to make some calls usually reserved for admins, whereas in a public cloud, this would be a remarkably bad idea. So if DefCore is going to enforce interoperability via tests, it should revise the tests to meet the most restrictive reasonable case. Image upload is a good example, as some cloud operators do not want to expose this operation to end users, period, and for a myriad of reasons (security, user frustration when the image from some large non-open-source cloud doesn't boot, etc.). With respect to tasks: the cloud provider specifies the exact content of the 'input' element. It's going to differ from deployment to deployment. But that isn't significantly different from different clouds having different flavors with different capabilities. You can't reasonably expect that "nova boot --flavor economy-flavor --image optimized-centos myserver" is going to work in all OpenStack clouds, i.e., you need to figure out the appropriate values to replace 'economy-flavor' and 'optimized-centos' in the boot call. I think the 'input' element is similar. The initial discussion was that it should be defined via documentation as we saw how tasks would be used in real life. But there's no reason why it must be documentation only. It would be easy to make a schema available. I tried to be as concise as possible, but now my email has gotten too long! cheers, brian [1] https://etherpad.openstack.org/p/havana-getting-glance-ready-for-public-clo uds [2] https://blueprints.launchpad.net/glance/+spec/upload-download-workflow [3] https://wiki.openstack.org/wiki/Glance-tasks-api [4] https://wiki.openstack.org/wiki/Glance-tasks-api-product [5] http://youtu.be/ROXrjX3pdqw [6] http://www.slideshare.net/racker_br/glance-tasksvancouver2015 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev