Issue #8439 has been updated by Daniel Pittman.
> The architecture fact is already supported in that it defaults to > hardwaremodel > > I’ve run into the following issues that make supporting these facts on > Windows non-trivial: > > The processor and processorcount facts on Linux refer to the number of > virtual/logical processors, which may include multicore or hyperthreaded > processors. On Windows, WMI provides the Win32_Processor class which > represents an instance of a physical processor. On 2003 and earlier it is > impossible to distinguish between physical and virtual processors. Does that mean a two physical, four virtual core machine would give "four" on that OS? > On 2008, > you can obtain the number of logical, but there’s no Win32_LogicalProcessor, > to actually give you details about the processor. In other words it does not > appear to be possible to provide the same semantics for the processor fact > on Windows, though processorcount (logical) and physicalprocessorcount could > be supported on 2008. Assuming that the first is true, I think a failure mode of over-estimating physical processors on Win2003 is quite acceptable. Even a failure mode of underestimating them (eg: virtual == physical) is probably acceptable. > WMI provides access to free and total physical memory , but the > Win32_PageFileSettings class, which contains total page file sizes, does not > work when automatic page fie management is enabled (which it is by default). Just don't export the fact, in that case. It really isn't super-important data for most people. > WMI provides access to some networking information, though Windows doesn’t > have a real loopback interface, and the WMI networking classes don’t include > it in their output. Instead it’s probably better to use netsh, which > provides output similar to ifconfig. For example, net interface ip show > addresses. Another windows quirk is that interface names are strings like > “Local Area Connection” instead of eth0. I generally agree that netsh should be used. > WMI does not provide any access to “am I running in a VM”. It does have > classes for a server that is hosting VMs I suspect that you will want to do something similar to the virtual fact, probably by abstracting it a bit, so that you can, for example, enumerate the PCI bus and look for the VMWare and similar "adapters". Most detection is pretty abstract; moving "is this PCI device connected" into helpers and implementing them for Win32 and Unix would be the best strategy. > Finally, facter does not provide a way to say this fact is not supported on > this platform. Instead you have to confine it to platforms where it is > supported. And we can’t have the ps fact return nil or “” on windows, > because facter will try a more general fact (the default one). So I don’t > see a way to make this change without making a change to facter itself. You can set a priority on a fact, these days, which will weight it above something with a longer set of platforms. However, I would absolutely expect the "ps" fact to either be confined to platforms where it works or, better, to be implemented for Win32. The concept (foolish as it is) of that fact would imply that either `tasklist` or `tlist` (if we support before XP) should be the right thing; IIRC, `tasklist /v` should be approximately the same thing. (Maybe with `/fo table` as well.) ---------------------------------------- Feature #8439: Basic facter on Windows https://projects.puppetlabs.com/issues/8439 Author: Josh Cooper Status: Accepted Priority: Normal Assignee: Josh Cooper Category: windows Target version: Telly Affected Puppet version: Keywords: Branch: The following facts are commonly available on non-Windows platforms and need to be implemented: * architecture * interfaces * ipaddress6 * memory * netmask * network * physicalprocessorcount * processor * is_virtual * virtual Also note the ps fact is wrong on Windows (reports ps -ef) -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
