On Sun, Jul 14, 2013 at 11:43:57PM -0600, Don Dugger wrote: > On Mon, Jul 01, 2013 at 09:43:58AM -0600, Don Dugger wrote: > > > > 1. Ultimately, I want to remove the periodic capability update > > completely. > > The better technique is to update compute node state when the state > > changes, periodic updates are just extra overhead.
It is easy enough for a node to refresh its list of flavours upon change too, so that's not really a blocker. > > 2. There's no concept of which nodes support which flavors so this is > > a completely new infrastructure that would have to be added to the > > scheduler. Again that's not a problem. We're not aiming for the least work solution here, we want the one that makes most sense from a design pov even if that requires extra dev work. > > 3. There's no easy way for the compute node to know which flavors it > > supports. It doesn't know which filters are enabled in the scheduler > > so it doesn't know which clauses of a flavor actually apply (ignoring > > that the compute node would now have to duplicate the filtering > > mechanism from the scheduler even if it knew which filters were > > enabled). I don't think that's an issue either. When the node filters the list of flavours, it is doing so based on criteria about what it is technically capable of supporting at a hardware level. When the schedular is filtering flavours it is doing so based on operational rules. The node doesn't need to take over the filtering that the scedular currently does. They are complementary filtering rules. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list