Open Stack

Excerpts from Monty Taylor's message of 2015-09-14 20:41:38 +0200:
> 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.

Part of the point of me starting this discussion now is to influence the
summit sessions the Glance team has, and the goals of those sessions.

> >
> >
> > (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.

Indeed, as I've said elsewhere I am going to work this cycle on
improving the two-way conversations with the DefCore committee and
the contributor community. DefCore has been very good at listening
to technical input when we make it available, and I think all of
our project teams need to engage more with them now that their
processes are settling down to something we can work with regularly.

> 
> 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.

This is more or less what I'm thinking we want, too. As a user, I want
to know how to import an image by having that documented clearly and by
using an obvious UI. As a deployer, I want to sometimes do things to an
image as they are imported, and background tasks may make that easier to
implement. As a user, I don't care if my image upload is a task or not.

> 
> >
> > (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.

Yeah, whether or not deployers use a thing is a separate criteria
for DefCore than whether we can make the thing work consistently
in more than one deployment. Regardless of whether DefCore adopts
an image upload criteria and associated test, we want a good image
upload API.

> 
> > With respect to tasks: the cloud provider specifies the exact content of
> > the 'input' element.  It's going to differ from deployment to deployment.

Can you explain why that needs to be the case?

> 
> 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 did find one example in the Rackspace API documentation.

> 
> > 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
> >
>