[ovirt-devel] [VDSM] [ENGINE] [RFC] A configuration verb for contexual vdsm operation mode

Roy Golan rgolan at redhat.com
Tue Apr 4 10:10:02 UTC 2017


On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <ykaul at redhat.com> wrote:

> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgolan at redhat.com> wrote:
>
> 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.
>
>
> Isn't it solved by host re-installation?
>

We allow maintenance + change host cluster so not always. Was this changed?

>
>
> # 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.
>
>
> How do we persist this level on VDSM? Or we don't, and if VDSM is
> restarted it is again back to 4.1 mode until Engine tells it otherwise?
> Y.
>

Must persist it somehow otherwise there is a race when the engine will send
send a stats request and will get the wrong answer.  I'm wondering if using
differnt endpoints is the right solution here to prevent that from
happening.
  method: Host.getStats version: 4.1


>
>
>
> Nevertheless it can be potentially beneficial to more functions in vdsm.
>
> Thanks,
> Roy
>
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170404/b971526c/attachment.html>


More information about the Devel mailing list