Glance

Bug #1545092
Comment #8

Comment 8 for bug 1545092

Revision history for this message

Nikhil Komawar (nikhil-komawar) wrote on 2016-02-12:

I am confirming that this issue is real. Thanks for raising this Brian, the description looks great.

However, I would like to elaborate a bit more on the problem, probably answering a few of fungi's questions.

I think the intent was to express the effect of loosely coupled image record creation, that is almost a no-cost operation to the user with that of the relatively heavy weight image activation process that includes data uploads.

I see there are a few problems here:

1. Image records that are created are put in queued status and are query-able (visible to the user). All the more, user can set the limited set of properties, tags etc. metadata on these images -- at a negligible cost.
2. glanceclient allows successful image creation without any parameters (glance image-create) -- cost to user is significantly reduced.
3. Although, a default page size is imposed on the query one may choose to include a upper limit on the page size thereby increasing the size and complexity of the image query. A large number of such images each, with significant number of image properties, tags, members can result into slowness of the response, sometimes even resulting into 500s.
4. Listing of image through the Nova proxy Images API will be even worse experience (as the image list will be returned as Glance DB -> Glance registry -> Glance API -> glanceclient -> Nova API -> user/novaclient. Likelyhood of 5xx responses is quite high in this case.
5. I am skeptical on the DOS here as modern day applications especially those that include geo-spatial data create so much more data in the DB. The question (to me at least) is of the query-able data (or in BigData term you can think of as Hot data).

I think we need to consider this affecting the v1 Images API too as that is still required to be deployed parallel to Nova and if exposed to users it will have the same effect (for the sake of completeness of the security impact).

Though the experience of the query or client (as described in the comments above) can be improved by imposing stricter defaults in the image-list query.

Thoughts?

I am confirming that this issue is real. Thanks for raising this Brian, the description looks great.

However, I would like to elaborate a bit more on the problem, probably answering a few of fungi's questions.

I see there are a few problems here:

1. Image records that are created are put in queued status and are query-able (visible to the user). All the more, user can set the limited set of properties, tags etc. metadata on these images -- at a negligible cost.
2. glanceclient allows successful image creation without any parameters (glance image-create) -- cost to user is significantly reduced.
3. Although, a default page size is imposed on the query one may choose to include a upper limit on the page size thereby increasing the size and complexity of the image query. A large number of such images each, with significant number of image properties, tags, members can result into slowness of the response, sometimes even resulting into 500s.
4. Listing of image through the Nova proxy Images API will be even worse experience (as the image list will be returned as Glance DB -> Glance registry -> Glance API -> glanceclient -> Nova API -> user/novaclient. Likelyhood of 5xx responses is quite high in this case. 
5. I am skeptical on the DOS here as modern day applications especially those that include geo-spatial data create so much more data in the DB. The question (to me at least) is of the query-able data (or in BigData term you can think of as Hot data).

Though the experience of the query or client (as described in the comments above) can be improved by imposing stricter defaults in the image-list query.

Thoughts?