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

Wed Apr 19 11:38:08 UTC 2017

On Tue, Apr 4, 2017 at 2:20 PM Piotr Kliczewski <pkliczew at redhat.com> wrote:

> I wonder why we not go in the same approach as we went for vm status
> changes. Why not to pull for older versions and expect a push from new
> implementation.
> This would allow as to keep current code as it is for backward
> compatibility purposes and create new one (reuse parts of the old one) for
> new approach.
> We could change stats collection (collectd based) and still get important
> data using push.
>
> If we want to pass cluster version we could use connection negotiation
> like we do for heartbeat interval. It can be passed every time engine
> connects so there is no
> need for persistence. We could define custom headers and as a result it
> won't break vdsm-client code.
>
>
Passing the cluster version isn't a problem. The main benefit would be to
spare precious cpu and memory for vdsm and for virtualization.

> Please note that we are not good at deprecating api and I am not going to
> say anything about cleanup or removal.
> Whatever we introduce it is going to stay so we need to be careful.
>
>
> On Tue, Apr 4, 2017 at 12: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.
>>
>>
>>>   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/f4f90400/attachment-0001.html>