Open Stack

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