I'm working on a POC lately on a change to stats collection and retrieval by VDSM. The moto is to cut all we can from host/vm stats (possibly caps) and report only core-business stuff to the engine. Engine will retrieve the rest through a 3rd party provider (nevermind what is it atm)Being backward compatible by design, I have to support 2 API versions for Host.getStats , '4.1' and '4.2'.Except from supplying less parameters, I want VDSM to do less stuff. It doesn't need to sample what it doesn't report. In other words I want '4.1-sampling' and '4.2-sampling'# Introducing 'configuration' Verb:As engine knows always(Hosted Engine as well) what cluster version this host belongs to, it can configure VDSM to operate in cluster version mode.
Host.configure(config={version: 4.2} Consider this verb, pre-activating using 'Host.getCaps' to set the context.
It will set the righjt sampling method, and other stuff if needed then API endpoints will have the right permutation of the api to answer it.4.2 host can operate in 4.1 mode:
Host.configure(config={version: 4.1} Issue: moving a 4.2 host from 4.2 cluster to 4.1 is a problem since engine needs to know this is a new vdsm that has the verb available. One way to overcome that is to fire the verb for every host regardless of the version and disregard an error that implies the verb doesn't exist.
# Engine:Engine will have a handling of the verb per version.Host/Vms monitoring should be changed - I suggest to move out of the monitoring code the whole stats collection as it is a different task which is orthogonal to 'monitoring' and in 4.2 more than before.I know configuration for VDSM has been discussed before and there are probably tons of ways to do it. When you share your thoughts please remember that configuration is a by-product of the effort.
Nevertheless it can be potentially beneficial to more functions in vdsm.Thanks,Roy
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel