On Tue, Apr 4, 2017 at 2:20 PM Piotr Kliczewski <pklic...@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.skriva...@redhat.com> wrote: > >> >> On 4 Apr 2017, at 12:21, Roy Golan <rgo...@redhat.com> wrote: >> >> >> >> On Tue, Apr 4, 2017 at 1:16 PM Michal Skrivanek < >> michal.skriva...@redhat.com> wrote: >> >>> On 4 Apr 2017, at 12:10, Roy Golan <rgo...@redhat.com> wrote: >>> >>> >>> >>> On Tue, Apr 4, 2017 at 12:49 PM Yaniv Kaul <yk...@redhat.com> wrote: >>> >>> On Tue, Apr 4, 2017 at 12:29 PM, Roy Golan <rgo...@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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> >> >
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel