Glance-upload-mechanism-reloaded

Glance upload-mechanism-reloaded meeting

Tuesday September 29, 2015 15:00 UTC Attendees: flaper87, sigmavirus24, dhellmann, jokke, nikhil_k, mclaren, sabari, rosmaita

I’d like to get feedback on whether this is an accurate summary of our discussion today.

Use Case

“Here are my bits, give me something I can boot an instance with.”

With a bit more precision: A cloud end-user has a bunch of bits that they want to give to Glance in the expectation that (in the absence of error conditions) Glance will produce an Image (record, file) tuple that can subsequently be used by other OpenStack services that consume Images.

Terminology

We’ve agreed that we’ll refer to the above use-case as “image import”. (This is consistent with the terminology used in other clouds.)

Parameters/Constraints

1. It is acceptable for there to be separate “image upload” and “image import” API calls, and it is acceptable for the image upload call to be restricted access (e.g., only available to sysadmins or other OpenStack services). The image import API call, however, must be available to non-admins.
2. The image import operation should fall under the “OpenStack Powered Compute” program. (In other words, it cannot assume the existence of an object store that is exposed to end-users.)
3. The image import operation must be discoverable.
4. The image import operation must be supported in DevStack.
5. The image import operation must be supported by the python-glanceclient, but the operation cannot require the presence of the glanceclient.
6. In the initial implementation, the deployer can specify a particular container_format, disk_format for the bit package to be imported. (Ultimately, we’d like to do conversion-upon-input from some set of supported formats into whatever format the particular cloud prefers to use.)
7. The bit-package supplied by the end-user does not have to be opaque, i.e., it is permissible to allow the cloud deployer to inspect-and-reject without creating an image.
8. The image import operation does not have to be implemented as a direct upload into Glance. (It could, e.g., be a “pull” from Glance to get the bits.) The key point is that it must work the same way in all deployments. (Although see the next point.)
9. It’s OK for the image import operation to be extensible, but to satisfy DefCore, all deployments must support the plain vanilla operation. For example, if an object store is available, it’s OK for the import operation to make use of the object store in some way as long as the normal non-object-store import operation is supported.
10. While we don’t necessarily have to do image export at the present time, we should design image import in such a way that image export will fit in naturally.

Next Steps

Once we’ve reached agreement on the above points (or articulated more clearly what they mean), rosmaita will circulate the agreed-upon summary of the direction we’re taking to the ML. I guess just put [glance][ops][product][api] etc., in the subject line? If so, let me know what should be included.

rosmaita will get a draft spec started as soon as some feedback is received (I’m not worried that there won’t be feedback!). I’m not sure at this point if it would be google doc or a regular Glance spec (let me know what you think).

rosmaita will propose a session for the Glance Mitaka design summit.

Open Questions

1. I need some help in teasing out exactly what “discoverable” means for the image import operation. For example, in what way is the current Images API discoverable?
2. How will the deployer’s preference of accepted container_format, disk_format be promulgated to the people? Particularly for public clouds, the deployer must be allowed to put a limit on the number of bytes that will be accepted (otherwise, as Stuart pointed out, a malicious user could tell Glance to grab bytes from a webapp that spits out an infinite number of bytes).
3. What are reasonable restrictions from the DefCore point of view?
4. How are these restrictions to be made known?
5. Are there other properties beyond container_format, disk_format that deployers should be allowed to specify?
6. I was going to add, “How will the DefCore Tempest tests test this feature?” but I guess if we’ve described the feature clearly the test cases will almost write themselves.