> There was a conversation earlier this week in which, if I understood > things correctly, one of the possible outcomes was that it might make > sense for the new placement service (which will perform the function > currently provided by the scheduler in Nova) to only get used over its > REST API, as this will ease its extraction to a standalone service.
FWIW, I think that has been the long term expectation for a while. Eventually that service is separate, which means no RPC to/from Nova itself. The thing that came up last week was more a timing issue of whether we go straight to that in newton or stop at an intermediate stage where we're still using RPC. Because of the cells thing, I was hoping to be able to go straight to HTTP, which would be slightly nicer than what is actually an upcall from the cell to the API (even though we're still pretty flat). > * The way to scale is to add more placement API servers and more > nodes in the galera (or whatever) cluster. The API servers just > talk to the persistence layer themselves. There are no tasks to > "conduct". I'm not sure that we'll want to consider this purely a data service. The new resource filter approach is mostly a data operation, but it's not complete -- it doesn't actually select a resource. For that we still need to run some of the more complicated scheduler filters. I'm not sure that completely dispensing with the queue (or queuing of some sort) and doing all the decisions in the API worker while we hold the HTTP client waiting is the right approach. I'd have to think about it more. > * If API needs to be versioned then it can version the external > representations that it uses. It certainly needs to be versioned, and certainly that versioned external representation should be decoupled from the actual persistence. > * Nova-side versioned objects that are making http calls in > themselves. For example, an Inventory object that knows how to > save itself to the placement API over HTTP. Argh. No. Magical > self-persisting objects are already messy enough. Adding a second > medium over which persistence can happen is dire. Let's do > something else please. Um, why? What's the difference between a remotable object that uses rabbit and RPC to ask a remote service to persist a thing, versus a remotable object that uses HTTP to do it? It seems perfectly fine to me to have the object be our internal interface, and the implementation behind it does whatever we want it to do at a given point in time (i.e. RPC to the scheduler or HTTP to the placement service). The indirection_api in ovo is pluggable for a reason... > * A possible outcome here is that we're going to have objects in Nova > and objects in Placement that people will expect to co-evolve. I don't think so. I think the objects in Nova will mirror the external representation of the placement API, much like the nova client tracks evolution in nova's external API. As placement tries to expand its scope it is likely to need to evolve its internal data structures like anything else. --Dan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
