On 10/27/14, 6:08 PM, "Jay Pipes" <[email protected]> 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 >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
