Open Stack

On 10/31/14, 3:21 AM, "Flavio Percoco" <flavio at redhat.com> wrote:

>On 28/10/14 22:18 +0000, Jesse Cook wrote:
>>
>>
>>On 10/27/14, 6:08 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>>
>>>On 10/27/2014 06:18 PM, Jesse Cook wrote:
>>>> In the glance mini-summit there was a request for some documentation
>>>>on
>>>> the architecture ideas I was discussing relating to: 1) removing data
>>>> consistency as a concern for glance 2) bootstraping vs baking VMs
>>>>
>>>> Here's a rough draft:
>>>>https://gist.github.com/CrashenX/8fc6d42ffc154ae0682b
>>>
>>>Hi Jesse!
>>>
>>>A few questions for you, since I wasn't at the mini-summit and I think
>>>don't have a lot of the context necessary here...
>>>
>>>1) In the High-Level Architecture diagram, I see Glance Middleware
>>>components calling to a "Router" component. Could you elaborate what
>>>this Router component is, in relation to what components currently exist
>>>in Glance and Nova? For instance, is the Router kind of like the
>>>existing Glance Registry component? Or is it something more like the
>>>nova.image.download modules in Nova? Or something entirely different?
>>
>>It's a high-level abstraction. It's close to being equivalent to the
>>cloud
>>icon you find in many architecture diagrams, but not quite that vague. If
>>I had to associate it with an existing OpenStack component, I'd probably
>>say nova-scheduler. There is much detail to be flushed out here. I have
>>some additional thoughts and documentation that I'm working on that I
>>will
>>share once it is more flushed out. Ultimately, I would like to see a
>>fully
>>documented prescriptive architecture that we can iterate over to address
>>some of the complexities and pain points within the system as a whole.
>>
>>>
>>>2) The Glance Middleware. Do you mean WSGI middleware here? Or are you
>>>referring to something more like the existing nova.image.api module that
>>>serves as a shim over the Glance server communication?
>>
>>At the risk of having something thrown at me, what I am suggesting is a
>>move away from Glance as a service to Glance as a purely functional API.
>>At some point caching would need to be discussed, but I am intentionally
>>neglecting caching and the existence of any data store as there is a risk
>>of complecting state. I want to avoid discussions on performance until
>>more important things can be addressed such as predictability,
>>reliability, scalability, consistency, maintainability, extensibility,
>>security, and simplicity (i.e. As defined by Rich Hickey).
>>
>
>Hi Jessee,
>
>I, unfortunately, missed your presentation at the virtual mini summit
>so I'm trying to catch up and to understand what you're proposing.
>
>As far as I understand, your proposal is to hide Glance from public
>access and just make it consumable by other services like Nova,
>Cinder, etc through a, perhaps more robust, glance library. Did I
>understand correctly?
>
>Or, are you suggesting to get rid of glance's API entirely and instead
>have it in the form of a library and everything would be handled by
>the middleware you have in your diagram?
>
>Cheers,
>Flavio
>
>-- 
>@flaper87
>Flavio Percoco

Hi Flavio,

The diagram suggest more of the latter than the former. However, neither
is quite right, and the glance's deployment and public interface is
ancillary.

The documentation I presented is a bit rough, and I need to make updates
to it (which I plan to get to over the next week or so). However, let me
clarify a few things.

1) Ability to obtain metadata or image information should not be taken
from the user.
2) Ideally glance would be stateless. Forget performance for a minute and
imagine glance without a cache or a database.
3) Metadata will be stored in the individual objects themselves (within
the object store).
4) The most important function of glance would be to provide a consistent
API for listing and filtering of objects. I can see an implementation
where glance provides an upload, download, and delete operation. I can
also see an implementation where these operations are not within the
glance core code. In either case these operations could be composed with
the list and filter operations.

It seems that glance is currently trying to perform several major
functions, instead of focusing on a single principle function:

1) Glance as a cache
   * Should this be the principal function of glance? I would say no.
Reinventing caching and turning it into a service doesn't seem to add the
most value.
   * Note: There seems to be debate about whether it should stay
write-through or become write-around
2) Glance as a metadata service
   * Should this be the principal function of glance? Again, I would say
no. Although this is much closer to the principal customer value, I don't
think it's quite on target.
   * This inherently suggests splitting data ownership between two parts
of the system which is a recipe for complex systems. The objects own the
data (arguably the object store, but this is a little nuanced), and glance
owns the metadata.
3) Glance as a consistent API
   * Should this be the principal function of glance? I think so. An
operator can switch between one or more object stores seamlessly without
impacting user capability.
   * This allows glance to focus on simple stateless operations such as
listing and filtering.

With a principal focus, performance can be improved through deliberate
enhancements to the stateless operations supported.

Thanks,

Jesse