[ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode
Roy Golan
rgolan at redhat.com
Tue Apr 4 09:29:32 UTC 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170404/38149a69/attachment-0001.html>
More information about the Devel
mailing list