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. > > > 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? > > 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' ? > > 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