On 28/10/14 22:18 +0000, Jesse Cook wrote:
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/8fc6d42ffc154ae0682bHi 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
pgp1eRLkbOF_A.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
