Open Stack

Excerpts from Kuvaja, Erno's message of 2015-09-15 09:43:26 +0000:
> > -----Original Message-----
> > From: Doug Hellmann [mailto:doug at doughellmann.com]
> > Sent: Monday, September 14, 2015 5:40 PM
> > To: openstack-dev
> > Subject: Re: [openstack-dev] [glance] proposed priorities for Mitaka
> > 
> > Excerpts from Kuvaja, Erno's message of 2015-09-14 15:02:59 +0000:
> > > > -----Original Message-----
> > > > From: Flavio Percoco [mailto:flavio at redhat.com]
> > > > Sent: Monday, September 14, 2015 1:41 PM
> > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > Subject: Re: [openstack-dev] [glance] proposed priorities for Mitaka
> > > >
> > > > On 14/09/15 08:10 -0400, Doug Hellmann wrote:
> > > > >
> > > > >I. DefCore
> > > > >
> > > > >The primary issue that attracted my attention was the fact that
> > > > >DefCore cannot currently include an image upload API in its
> > > > >interoperability test suite, and therefore we do not have a way to
> > > > >ensure interoperability between clouds for users or for trademark
> > > > >use. The DefCore process has been long, and at times confusing,
> > > > >even to those of us following it sort of closely. It's not entirely
> > > > >surprising that some projects haven't been following the whole
> > > > >time, or aren't aware of exactly what the whole thing means. I have
> > > > >proposed a cross-project summit session for the Mitaka summit to
> > > > >address this need for communication more broadly, but I'll try to
> > summarize a bit here.
> > > >
> > >
> > > Looking how different OpenStack based public clouds limits or fully
> > prevents their users to upload images to their deployments, I'm not
> > convinced the Image Upload should be included to this definition.
> > 
> > The problem with that approach is that it means end consumers of those
> > clouds cannot write common tools that include image uploads, which is a
> > frequently used/desired feature. What makes that feature so special that we
> > don't care about it for interoperability?
> > 
> 
> I'm not sure it really is so special API or technical wise, it's just the one that was lifted to the pedestal in this discussion.

OK. I'm concerned that my message of "we need an interoperable image
upload API" is sometimes being met with various versions of "that's not
possible." I think that's wrong, and we should fix it. I also think it's
possible to make the API consistent and still support background tasks,
image scanning, and other things deployers want.

> <CLIP>
> > > >
> > > > The task upload process you're referring to is the one that uses the
> > > > `import` task, which allows you to download an image from an
> > > > external source, asynchronously, and import it in Glance. This is
> > > > the old `copy-from` behavior that was moved into a task.
> > > >
> > > > The "fun" thing about this - and I'm sure other folks in the Glance
> > > > community will disagree - is that I don't consider tasks to be a
> > > > public API. That is to say, I would expect tasks to be an internal
> > > > API used by cloud admins to perform some actions (bsaed on its
> > > > current implementation). Eventually, some of these tasks could be
> > > > triggered from the external API but as background operations that
> > > > are triggered by the well-known public ones and not through the task
> > API.
> > > >
> > > > Ultimately, I believe end-users of the cloud simply shouldn't care
> > > > about what tasks are or aren't and more importantly, as you
> > > > mentioned later in the email, tasks make clouds not interoperable.
> > > > I'd be pissed if my public image service would ask me to learn about tasks
> > to be able to use the service.
> > >
> > > I'd like to bring another argument here. I think our Public Images API should
> > behave consistently regardless if there is tasks enabled in the deployment or
> > not and with what plugins. This meaning that _if_ we expect glance upload
> > work over the POST API and that endpoint is available in the deployment I
> > would expect a) my image hash to match with the one the cloud returns b)
> > I'd assume all or none of the clouds rejecting my image if it gets flagged by
> > Vendor X virus definitions and c) it being bootable across the clouds taken it's
> > in supported format. On the other hand if I get told by the vendor that I need
> > to use cloud specific task that accepts only ova compliant image packages and
> > that the image will be checked before acceptance, my expectations are quite
> > different and I would expect all that happening outside of the standard API
> > as it's not consistent behavior.
> > 
> > I'm not sure what you're arguing. Is it not possible to have a background
> > process import an image without modifying it?
> 
> Absolutely not my point, sorry. What I was trying to say here is that I rather have multiple ways of getting images into cloud I use if that means I can predict exactly how those different ways behaves on each deployment that has them enabled. My thought of tasks has been more on the processing side than just different way to do upload. So I have been in understanding that the intention behind tasks were to provide extra functionality like introspection, conversion, ova-import (which is under work currently), many of that would be beneficial for the end user of the cloud, but happening to your image as side effect of image upload without you knowing or able to avoid it, not so desirable state.

Ah, yes. But most people don't care about how all of the internals work.
They just want to upload an image, and they don't want to have to learn
15 different ways to do it. As I've said, a pull API that uses a
background task to import the image is fine, as long as the inputs and
outputs of the API itself are the same all the time. It's also fine to
have deployers add background steps, to some extent. If the API works
and a deployer's background job breaks my image, I'll be upset, but as a
user I can point directly to them in that case. If the APIs are
different everywhere, I'm not even sure where to start.

Doug