[FACT-231]
Created: 2014/01/18 Updated: 2014/11/07 Resolved: 2014/04/05
Status: Closed
Project: Facter
Component/s: Community
Affects
Version/s:
None
Fix Version/s: FACT 2.1.0
Type: Task
Reporter: gepetto-bot
Resolution: Fixed github Labels:
Remaining
Estimate:
Not Specified
Time Spent:
Original
Estimate:
Template:
Not Specified
Not Specified customfield_10700 true
Story Points: 1
Week 2014-4-02 to 2014-4-09 Sprint:
Description
Priority:
Assignee:
Votes:
Normal
Unassigned
2


Author: Samuel Keeley <sam@keeleysam.com>
 Company:
 Github ID: keeleysam
Pull Request 608 Discussion
 Pull Request 608 File Diff
Using SPDisplaysDataType causes lagging issues on pre-2013 Macs, so use other sources from system_profiler which do not have the issue and are also more reliable.
(webhooks-id: a67fb3d75a6d500d1f4bc6ed458c99b7)

Comments
Comment by Nate Walck
[ 2014/01/19 ]
Can this get targeted for 1.7.5? It is a rather big issue for anyone using puppet on pre-2013 hardware. This especially effects anyone who does design work that requires precision cursor movement and is a huge annoyance to them (not to mention it hinders their ability to work).
Thanks!
Nate
Comment by Samuel Keeley
[ 2014/01/19 ]
The issue is most evident when a user is moving the mouse or listening to music, as these will stutter. It does not occur on new Macs, but definitely happens on all 2011 and older Macs, in addition to some 2012 Macs.
This is somewhat of a workaround for an Apple bug, but it also enhances detection if using
ESXi and an assigned PCI-E video card instead of the emulated one from the hypervisor.
Comment by gepetto-bot
[ 2014/01/19 ] glarizza commented:
I'm positive the Facter team will review your pull request, but just a heads up - this looks like it would cause some build failures ( https://travis-ci.org/puppetlabs/facter/jobs/17210641 ) in the spec tests, specifically these tests --> https://github.com/puppetlabs/facter/blob/master/spec/unit/virtual_spec.rb#L50-L74
If you feel comfortable, can you take a look at submitting a commit to update the tests in line with your pull request?
Comment by gepetto-bot
[ 2014/01/19 ] keeleysam commented:
Thanks for the heads-up. I did actually update the tests, just forgot to git add them! Doing that now.
Comment by Gary Larizza
[ 2014/01/19 ]
Some more background info on the issue, for posterity --> http://patternbuffer.wordpress.com/2013/05/05/cursor-tracking-lag-caused-by-system_profiler/
Comment by Nate Walck
[ 2014/02/04 ]
Is it likely that this will hit in facter 1.7.6? I know 1.7.5 is nearly out, so it was too late to make that release.
Comment by Jesse Endahl
[ 2014/03/10 ]
Gary Larizza Nigel Kersten Zachary Smith can we get this merged?
Comment by gepetto-bot
[ 2014/03/12 ] ahpook commented:
We are in kind of a weird place with regard to facter pulls right now because we're in 2.0 RC and do not have another 1.7.x release planned. That said we'd like to get this in a release, especially now that tests are passing. @adrienthebo can you look at this in the next PR triage and see if it can get into both pe_facter and future oss releases?
Comment by gepetto-bot
[ 2014/03/12 ]

adrienthebo commented:
@glarizza I'm not an OSX expert, are you okay with this approach for getting this data? If so we can merge it.
Comment by gepetto-bot
[ 2014/03/12 ] keeleysam commented:
I have check all versions of Fusion, VMware Fusion/ESXi, and Parallels, and it they all show the same, it does not need to be case insensitive.
Comment by gepetto-bot
[ 2014/03/13 ] adrienthebo commented:
This looks good, but before we merge this it would be good to do a little bit of bookkeeping. I can't recall if I already asked for this but it would be good to have a JIRA issue associated with this issue. In addition the commits should be squashed into a single commit, and the commit message should be updated to match the format in https://github.com/puppetlabs/facter/blob/master/CONTRIBUTING.md#making-changes .
These changes make it easier to understand what was done here in case we need to review this later. Thanks
Comment by gepetto-bot
[ 2014/03/13 ] ahpook commented:
@adrienthebo https://tickets.puppetlabs.com/browse/FACT-231
Comment by Adrien Thebo
[ 2014/04/03 ]
Merged in f221887.
Comment by Kurt Wall
[ 2014/04/04 ]
Verified in facter-2.0.1-f2218870474e58813b5722844a16fc7aeeaf1182.
$ facter | egrep -i "vm|virt" blockdevice_sda_model => VMware Virtual S blockdevice_sda_vendor => VMware, blockdevice_sr0_model => VMware IDE CDR10 blockdevice_sr0_vendor => NECVMWar is_virtual => true manufacturer => VMware, Inc. productname => VMware Virtual Platform serialnumber => VMware-56 4d 15 8f 0b 65 95 ba-f4 2d 45 40 f7
7c 73 ee virtual => vmware
Comment by Adrien Thebo
[ 2014/04/04 ]
Eugene Vilensky why was this issue reopened?
Comment by Eugene Vilensky
[ 2014/04/04 ]
Adrien Thebo A mis-placed click. All apologies, hadn't realized I had done that.
Comment by Adrien Thebo
[ 2014/04/05 ]

Eugene Vilensky got it, thanks for clarifying that
Comment by Tim Sutton
[ 2014/07/02 ]
For VMware Fusion, searching "VMware" in machine_model won't always suffice. VMware
Fusion supports at least two additional hardware settings in VMX that can spoof a real hardware model like "MacBookPro10,2". Setting either "hw.model" to the desired string or
"hw.model.reflectHost" to "TRUE" will give a machine_model that's not like "VMware7,1".
It's probably mostly a corner case, but sometimes one needs to spoof the model name in order to test any conditional logic that would use hardware identifier value, or for applications/installer logic that might depend on this value.
For example, the same facter output on my Mountain Lion Fusion VM that has guest tools installed and an explicitly-set hw.model in its VMX:
$ facter | egrep -i "vm|virt" fqdn => test-vm-ml.domain.my hostname => test-vm-ml is_virtual => false sp_boot_rom_version => VMW71.00V.0.B64.1310020058 sp_local_host_name => test-vm-ml sp_secure_vm => secure_vm_enabled sp_serial_number => VMWVk0+Ybd6rKeIJ4kU0VBcjg virtual => physical
One possible approach might be to scan the boot_rom_version similar to how the Parallels check works, in virtual.rb: require 'facter/util/macosx' result = "physical"
# use SPHardwareDataType for VMware and VirtualBox, since it is the most
# reliable source. output =
Facter::Util::Macosx.profiler_data("SPHardwareDataType") if output.is_a?(Hash)
result = "vmware" if output["boot_rom_version"] =~ /VMW/
result = "virtualbox" if output["boot_rom_version"] =~
/VirtualBox/ end
The Boot ROM Version on my VM here is "VMW71.00V.0.B64.1310020058"
Generated at Tue Feb 09 09:49:40 PST 2016 using JIRA 6.4.12#64027sha1:e3691cc1283c0f3cef6d65d3ea82d47743692b57.