On 09/14/2015 04:58 PM, Brian Rosmaita wrote:
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.)
I'm very sorry that I did not participate in that. I apologize heartily.
honestly, I do not think we realized how broken this system was until
Infra started trying to move to creating our base images once and
uploading them to each of our cloud regions, which then resulted in me
needing to write an entire compatibility library because the differences
in approaches were so radically and intractably different between the two.
It's possible that humans could have picked up on the pain this would
cause for the user if more of us had been in the sessions - but it's
also possible we would have missed it. I TOTALLY understand the logic
and reasoning - sometimes things that make perfect sense on paper just
flat fall over when they see the light of day. That's not a condemnation
of the people who worked on it - we all try things, and sometimes they
work and sometimes they do not.
This did not work, and it's time we all acknowledge that and make plans
to move forward.
(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.
Sure. But it's not the deployers that I care about on this point. I'm
sure it's awesome for them.
As a person _using_ this I can tell you it is utterly living hell. It
is, without a doubt, and with no close rivals, the hardest thing to
interact with in all of OpenStack.
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.
IMHO - a cloud that does not allow me to upload images is not a usable
cloud.
A cloud that requires me to upload images differently than another cloud
is a hardship on the users.
A cloud that makes the user know the image format of the cloud is a
hardship on the users, especially when there exist nowhere in any
existing distro tools that can actually produce the image format in
question. (yup, Im just going to sneak that one in there)
NOW - I think that the task api and the image conversion tools itself if
it's a behind the scenes kind of thing is potentially nice thing.
If "glance import-from http://example.com/my-image.qcow2' always worked,
and in the back end generated a task with the task workflow, and one of
the task workflows that a deployer could implement was one to do
conversions to the image format of the cloud provider's choice, that
would be teh-awesome. It's still a bit annoying to me that I, as a user,
need to come up with a place to put the image so that it can be
imported, but honestly, I'll take it. It's not _that_ hard of a problem.
(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.).
Those cloud providers need to get out of the game, at least in terms of
being able to call themselves OpenStack clouds. I respect that choice,
but it doesn't mean that we have to make bad software just because they
have made that choice.
With respect to tasks: the cloud provider specifies the exact content of
the 'input' element. It's going to differ from deployment to deployment.
Any time the exact content for a REST API call is going to differ from
cloud to cloud is a time that we have failed as a community. You are
right - this is the case today. It's why the task API is not suitable
for an end user API - it requires the end user to have specific
foreknowledge of deployer choices that are not exposed or discoverable
via the OpenStack API.
But that isn't significantly different from different clouds having
different flavors with different capabilities.
Untrue - because the 'nova flavor-list' shows you the qualities of
flavors. You can introspect using normal OpenStack tools what the
different flavors are.
That flavors have names is at best a quirky fun game.
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.
Right. This is the reason we don't use flavor names in any of Infra but
instead specify flavors by their min-ram. however, even in the case
where we can't purely use parameters and need to use filters on names
(like performance vs. non-performance flavors) we can visually inspect
the descriptive names via nova flavor-list.
This is not possible with the input to the task-create command. You have
to know things. In fact, I think you have to learn the magic json to
pass to the command line tool by reading a blog post. That's not ok.
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.
The thing is - I totally hear all of the places where this _could_ be
different per cloud, but in reality almost all of the clouds that are
out there are actually doing almost all of these things in a way that is
identical, or where there are differences there are sanely discoverable
differences. Where there are legitimate places for cloud providers to
make different choices in implementation, which I think are important
for our community - we MUST work to make the user interface not reflect
those.
Glance is currently the main place where the vendor choices are not able
to be sorted out in a sane manner by the end user. Luckily for people
who care about interop there is exactly one deployment that exposes the
task API, so the digging to figure out what random values of JSON a user
has to pass to the magic incantation has only had to be done once.
I would recommend that, since there is only one public instance of this,
we put the genie back in the bottle, make "glance import-from" spawn off
a task in the background and make the task API be marked admin-only in
the default policy.json. This still allows for the deployer to have the
flexibility to use the plugin system, which is awesome ... and further
empowers the deployer to make backend choices that they want to but to
hide the complexities of that from their users (so that users do not
have to know that these clouds take qcow2, these clouds take VHD and
these clouds take RAW)
I tried to be as concise as possible, but now my email has gotten too long!
Oh golly. I don't think I've ever written a short one - sorry for
increasing the total aggregate length.
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
