Description of problem: The columns in host dynamic: - physical_mem_mb - cpu_model - cpu_cores - cpu_cores - cpu_speed_mh - host_os - kernel_version - kvm_version - software_version And this column in host statistics: - swap_total are static and should be moved to host static.
why are they static? host memory, number of cpu, os, kernel, etc. can be changed at host level and are detected by the system, while static tables are mostly for changes initated from the engine/user side?
(In reply to comment #1) > why are they static? > host memory, number of cpu, os, kernel, etc. can be changed at host level > and are detected by the system, while static tables are mostly for changes > initated from the engine/user side? Static means that they do not change often and these columns don't change often at all. How often do you add memory or upgrade os? Once a year? that's static.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
still relevant
Seems hard to fix we treat 'Static' as all the fields known to the engine and 'dynamic' as all the fields for which we get a value from VDSM. So the terminology is confusing , I agree that those names are bad , but can not see how we can change that in the near future
Isn't there a plan to make changes from vdsm be push vs the current pull method? Will this not enable us to create real change level based tables? Yaniv
(In reply to Yaniv Dary from comment #6) > Isn't there a plan to make changes from vdsm be push vs the current pull > method? > Will this not enable us to create real change level based tables? > > > Yaniv I can not see how this is related
(In reply to Eli Mesika from comment #7) > (In reply to Yaniv Dary from comment #6) > > Isn't there a plan to make changes from vdsm be push vs the current pull > > method? > > Will this not enable us to create real change level based tables? > > > > > > Yaniv > > I can not see how this is related That this task can now change tables at a lower rate and allow move of columns to mixed controlled tables.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Pushing to 4.1, to look at when we strive to move to metrics and do some additional cleanup. I also don't think it's a bug but RFE. And I'm not sure what the impact on the user is.