Open Stack

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

>
>3) Images in Glance are already immutable, once the image bytes are
>actually uploaded to a backend block store. What conceptual differences
>are you introducing with the idea of object immutability?

I think the biggest difference is the object definitions themselves. These
objects are immutable, but contain history. Every "mutation" of the object
results in a new object with the history updated. Deleted binary data
(i.e. diff disks and overlays) would be truly deleted, but it's previous
existence will be recorded.

>
>4) How does the glance_store library play into your ideas, if at all?

I expect the glance_store library would contain much of the code that
would be required. However, what I have documented is at a higher level.

>
>5) How does the existing "image locations" collection in the Glance v2
>API work with your ideas? With an image uploaded to multiple locations
>(in Swift, Ceph clusters, wherever...), is the Router object in your
>architecture the thing that determines affinity for the best
>storage-locality to pull data from?

I don't know that where the data is stored is important in the context of
this conversation yet. I think it will become part of a more specific
conversation. Ultimately, though I believe this is one of the values that
Glance as Middleware would provide. It transparently performs the
operations documented over the object store(s).

>
>All the best,
>-jay

There are many important points that this documentation has not yet
addressed. Ideas such as discoverability, priority, performance, etc. This
is not because they are not important or that they haven't been
considered. It is because they are secondary to the primary goal:
simplicity. The OpenStack architecture as a whole has many complexities
build into it. Issues such as data consistency, state, time, etc. are
interwoven through various pieces of the system. These things have reared
their ugly head in many places. I would like to make a shift in
perception. One in which the design and architecture is more functional.
That doesn't mean a functional implementation. It does, however, mean that
there would be a real focus on unbraiding state from the components of the
system. Does this mean a massive rewrite? Well, no, but we might have to
slowly strangle parts of the system with stateless components.

Why Glance? The answer is three fold. Three major components of many use
cases are Nova, Glance, and the Object Store. Glance is right in the
middle. That's 1. I started in Glance. That's 2. Glance has been having
discussions about it's mission statement, which means that it seems to be
open to the idea there should be some sort of change. That's 3.

A final note. Some of the documentation that I am working on is already
starting to rope in Nova, Swift, and Repose.

Jesse

>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev