Hi Alex,

On Mon, Dec 10, 2012 at 8:44 PM, Alex Harvey <alexharv...@gmail.com> wrote:
> Hi all,
>
> This follows discussion on puppet users with Andrew Beresford
> https://groups.google.com/forum/?fromgroups=&pli=1#!topic/puppet-users/rOj9OszhlQM
>
> I was hoping to get more input from the community; now trying puppet
> developers for some advice.
>
> Summary of discussion is we've found the processorcount fact counts CPU
> threads on linux but CPU cores on Solaris.  The behavior on Solaris
> violates the principle of least surprise for my colleagues and I.  Our first
> reaction was it is a bug.  Question is what we can do about it now that
> these facts are out there in the wild.

I feel your pain having done this recently on Windows[1]. On Windows,
processorcount counts logical CPUs (which may include multicore or
hyperthreaded CPUs), and physicalprocessorcount counts physical CPUs
(not cores).

> Andrew Beresford (who found conversely that the linux behavior was more
> surprising to him) suggested we create new facts - processorcorecount and
> processorthreadcount and then deprecate processorcount.  I'm a bit agnostic
> on the matter.  Certainly I can't volunteer to implement the new facts on
> all platforms for lack of both time and access to all the platforms to test
> on.

I agree that creating a new fact to count CPU cores is preferrable
I'm not sure we need to deprecate processorcount, since it's already
established to mean processorthreadcount, at least on Linux, but
Solaris users may disagree.

>
> Another option presumably is simply to change the Solaris processorcount
> fact to do the same as what it does on linux.  This could arguably be
> described as either a bugfix or a non-backwards compatible change depending
> on your perspective.  Certainly, having the fact count different things on
> Solaris & Linux appears to be an error.
>

In cases were I find a Windows fact is wrong, e.g. architecture[2],
domain[3], I've taken the route that it's better to fix the bug and
make it consistent with other platforms, than to not do so for fear of
making a backwards incompatible change. With that said, it's good to
think about the impact changing a fact's semantics will have, and
whether the benefit outweighs the pain. In the case of the domain
fact, Windows nodes with a primary dns suffix, but no
connection-specific suffixes were reporting an empty domain. Clearly
fixing the fact was the right thing to do, but it meant users had to
regenerate their windows agent certificates (due to the default
certname being based on the fqdn).

> Anyhow would be good to get the advice of Puppet Labs on this one.
>
> Best regards,
> Alex Harvey
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-dev/-/GZEBOO_xeoMJ.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.

Josh

[1] http://projects.puppetlabs.com/issues/8439#note-2
[2] http://projects.puppetlabs.com/issues/10261
[3] http://projects.puppetlabs.com/issues/12864

--
Josh Cooper
Developer, Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to