Puppet users - Apr 2007 - Preferred method for setting customer facts?

I''ve checked out the page on adding custom facts for Facter and I see
that there are a number of ways to do this.  Is there a preferred method
of setting system-wide facts?

In this case, I''d like to set a "Location" fact which
represents the
data centre a server is in.

Cheers,

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************

On Apr 5, 2007, at 12:20 AM, HARRIS Jimmy ((AXA-Tech-AU)) wrote:
> I''ve checked out the page on adding custom facts for Facter and I
see
> that there are a number of ways to do this.  Is there a preferred  
> method
> of setting system-wide facts?
>
> In this case, I''d like to set a "Location" fact which
represents the
> data centre a server is in.
It''s really a question of information source.  If the information  
you''re using to derive the fact comes from the client, then it should  
be a client fact, created with a Ruby fact, probably that you  
download using --factsync.  If it''s a centralized decision, made from  
the IP address or something, it probably makes more sense to use a  
parser function.

There''s no real right or wrong answer, though.

  --
  Health is merely the slowest possible rate at which one can die.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

<snip>
> > Is there a preferred method of setting system-wide facts?
> >
> > In this case, I''d like to set a "Location" fact
which represents the
data centre a server is in.
> 
> It''s really a question of information source.  If the 
> information you''re using to derive the fact comes from the 
> client, then it should be a client fact, created with a Ruby 
> fact, probably that you download using --factsync.  If it''s a 
> centralized decision, made from the IP address or something, 
> it probably makes more sense to use a parser function.
This would be a per-server client fact that would get configured at
installation and be unlikely to change.

Do you have more information on --factsync or is that the internal way
that the server is able to see and use client facts?

Cheers,

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************

On Apr 5, 2007, at 12:41 AM, HARRIS Jimmy ((AXA-Tech-AU))
wrote:
>
> This would be a per-server client fact that would get configured at
> installation and be unlikely to change.
Based on what information?  Could it be calculated, or does it get  
set in a file or something?
> Do you have more information on --factsync or is that the internal way
> that the server is able to see and use client facts?
http://reductivelabs.com/trac/puppet/wiki/AddingFacts

It''s not my document (thanks, Charles et al!), but it''s what
you''re
looking for.

Looks like it wasn''t linked to in the sidebar; that''s fixed
now.

  --
  At my lemonade stand I used to give the first glass away free and  
charge
  five dollars for the second glass. The refill contained the antidote.
      -- Emo Phillips
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

> > This would be a per-server client fact that would get configured at 
> > installation and be unlikely to change.
> 
> Based on what information?  Could it be calculated, or does 
> it get set in a file or something?
Theoretically I''m sure that it could be calculated from the IP address
but that would require a degree of co-operation from our Network
Engineering team that I''m unlikely to get.  ;-)

I plan to set the location in a plain text file somewhere (possibly
/etc/axa-tech) along with some other information that will change very
infrequently, if at all, like rack location and RU.

A format of something like:

location:melbourne
rack:mel3
ru:34-36

should be easy enough to create facts from as well as use with our
existing scripts.
> > Do you have more information on --factsync or is that the 
> internal way 
> > that the server is able to see and use client facts?
> 
> http://reductivelabs.com/trac/puppet/wiki/AddingFacts
> 
> It''s not my document (thanks, Charles et al!), but it''s
what
> you''re looking for.
Yes, that''s exactly what I''m looking for.  Thanks Luke (and
particularly
Charles et al)...

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************