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

[Roy Golan]

On Tue, Apr 4, 2017 at 1:28 PM Michal Skrivanek <michal.skrivanek at redhat.com>
wrote:

> On 4 Apr 2017, at 12:21, Roy Golan <rgolan at redhat.com> wrote:
>
>
>
> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek <
> michal.skrivanek at redhat.com> wrote:
>
>> On 4 Apr 2017, at 12:10, Roy Golan <rgolan at redhat.com> wrote:
>>
>>
>>
>> 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)
>>
>>
>> I hope it’s the same one as for VM stats, collectd:)
>>
>
> Intended for this as well.
>
>
> great!
>
>
>>
>> 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.
>>
>>
>> why not running it in parallel for one version?
>>
>> What is the benefit?
>
>
> just so you do not need any configuration verb nor persistence, not much
> else.
>
> I'm trying to figure out, based on fromani's work, how much overhead the
sampling cause. If it is quite a bit cpu and memory we can spare then it is
definitely worth shutting it off selectively.

>
>>   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
>>
>>
>> would it be a problem? assuming that the code is easily started/stopped
>> within vdsm, we can just change the behavior based on receiving one or the
>> other verb for the first time after vdsm starts
>>
>
> But we should prefer a deliberate action. Doing that as a side effect is
> surprising for an API verb. What would happen in case you invoke
> 'vdsm-client’ ?
>
>
> I do not mean to switch for any client, more like a single “upgrade” of
> communication once the new verb is called. So once the engine calls the new
> verb the legacy stats thread is stopped and vdsClient <oldVerb> stops
> returning meaningful data.
> Actually, moving host back to older cluster doesn’t really need switching
> back either - you still have the new engine capable of handling the new
> verb despite older cluster.
>
>
>
>
>>
>> Thanks,
>> michal
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> 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/20170419/7c62a9aa/attachment-0001.html>