Open Stack

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>