On Oct 8, 2015, at 10:24 AM, Joshua Harlow <harlo...@outlook.com> wrote:
<some code snipped> > Now if we imagine each/all schedulers having watches > on /nova/compute_nodes/ ([2] consul and etc.d have equivalent concepts > afaik) then when a compute_node updates that information a push > notification (the watch being triggered) will be sent to the > scheduler(s) and the scheduler(s) could then update a local in-memory > cache of the data about all the hypervisors that can be selected from > for scheduling. This avoids any reading of a large set of data in the > first place (besides an initial read-once on startup to read the > initial list + setup the watches); in a way its similar to push > notifications. Then when scheduling a VM -> hypervisor there isn't any > need to query anything but the local in-memory representation that the > scheduler is maintaining (and updating as watches are triggered)... You've hit upon the problem with the current design: multiple, and potentially out-of-sync copies of the data. What you're proposing doesn't really sound all that different than the current design, which has the compute nodes send the updates in their state to the scheduler both on a scheduled task, and in response to changes. The impetus for the Cassandra proposal was to eliminate this duplication, and have the resources being scheduled and the scheduler all working with the same data. -- Ed Leafe
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
