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 :|