On Feb 21, 2009, at 7:06 PM, AJ Christensen wrote:
> My 2c on the matter is that JSON is the fastest, most portable, and
> supports all of the big boy data structures.
I'd vote for JSON also.
--~--~-~--~~~---~--~~
You received this message because you are subscr
I'd vote for the push to Marshal over YAML since Marshal appears to be
nothing more than a serialized instance of a data structure.
There should definitely be a way to pass arrays though.
I'm currently getting around that by using a comma separated string
and running a 'split' on any facts that
+1 for this.
I think that it is vital to make facter (the core) as fast as
possible. If it is really easy to crate new facts in arbitrary
languages (I'm looking forward to this :), then facter already does
enough of forking.
Internally, I would represent facts as that as what they are...
Given the pretty poor performance of yaml is it really an ideal choice
for ibternal representations?
The benefit of yaml is that it is human readable. I don't think it
makes sense internally.
My 2c.
On 2/18/09, Andreas Rogge wrote:
> Am Donnerstag, den 05.02.2009, 00:08 -0600 schrieb Luke Ka
Am Donnerstag, den 05.02.2009, 00:08 -0600 schrieb Luke Kanies:
> On Jan 30, 2009, at 6:10 AM, Mike Pountney wrote:
>
> > I like this idea, but how would it work in both facter output (would
> > it force us to use a rich output format for instance?) and puppet
> > itself?
>
> This is still undeci
On Feb 17, 2009, at 12:09 PM, Rob McBroom wrote:
>
> On Jan 29, 4:55 pm, James Turnbull wrote:
>>
>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> What about LDIF? Since Puppet can pull info from LDAP, it would be
> nice if facter made it easy to a
On Jan 29, 4:55 pm, James Turnbull wrote:
>
> 2. Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
What about LDIF? Since Puppet can pull info from LDAP, it would be
nice if facter made it easy to add/update entries in your directory.
--~--~-~--~~--
I'm not sure this is relevant, too late or simply already implemented,
but I'd like to have array of facts.
A very good example is the "ssh_keys" resource: i'd like to access
$ssh_keys['root'] and distributed that as an authorized_keys to other
nodes. I need this for my backups. :)
I'm sure it
On Fri, Feb 13, 2009 at 4:49 PM, Jeff Falgout wrote:
> On Fri, Jan 30, 2009 at 7:58 AM, Ross McKerchar
> wrote:
>
>
>> As I'm not great at ruby, I find writing facts and distributing them to do a
>> really simple thing can be a bit painful. Along these lines what about:
>>
>
> As Luke put it fo
On Fri, Jan 30, 2009 at 7:58 AM, Ross McKerchar
wrote:
> As I'm not great at ruby, I find writing facts and distributing them to do a
> really simple thing can be a bit painful. Along these lines what about:
>
As Luke put it for python - ruby makes my eyes bleed - I struggle
with Ruby a lot
On Wed, Feb 4, 2009 at 10:08 PM, Luke Kanies wrote:
> There are basically three choices here, from what I see:
>
> * A file containing a simple value
>
> * An executable file that produces a value
>
> * A yaml/json/xml/foo-encoded file that describes metadata necessary
> to determine a value. T
On Feb 1, 2009, at 10:42 PM, Nigel Kersten wrote:
> On Sun, Feb 1, 2009 at 10:41 AM, Paul Lathrop
> wrote:
>>
>> I don't think that belongs in facter; it belongs in the fact itself.
>
> Sure, but should everyone have to write the same code to do it?
>
> Why not have a simple declaration in you
On Feb 1, 2009, at 1:18 AM, Sam Rowe wrote:
>
> Oh and one other thing about 'facter.d' it'd be cool if there was some
> way to say that a given fact (or set of facts) is cache-able. Perhaps
> your fact is resource intensive to discover and doesn't change much.
> It'd be cool to have a built-in f
On Feb 1, 2009, at 1:07 AM, Sam Rowe wrote:
> I'm guessing this isn't the variety of feedback you're looking for,
> but just in case:
>
> We recently upgraded a couple of machines from facter 1.3.x to facter
> 1.5.x and were very dismayed to learn that $operatingsystemrelease on
> Solaris had cha
On Jan 31, 2009, at 9:31 AM, Don Jackson wrote:
>
>
>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> I'd vote for adding an optional output format to easily support
> shell scripts:
>
> Here is the shell compatible output of another tool I use:
>
>
On Jan 30, 2009, at 6:10 AM, Mike Pountney wrote:
>
>
> On 30 Jan 2009, at 10:24, James Turnbull wrote:
>> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
>> network -> interface -> ipaddress.
>
> I like this idea, but how would it work in both facter output (would
> it force
On Jan 30, 2009, at 3:40 AM, udo waechter wrote:
>
> Hello,
> On 29.01.2009, at 22:55, James Turnbull wrote:
>
>>
>> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
>> network -> interface -> ipaddress.
> This would be a great thing to have. Additionally it would be cool to
>
On Sun, Feb 1, 2009 at 10:41 AM, Paul Lathrop wrote:
>
> I don't think that belongs in facter; it belongs in the fact itself.
Sure, but should everyone have to write the same code to do it?
Why not have a simple declaration in your fact that gives you the
behavior you want?
>
> Just my .02
>
In general I agree, and thats how I've implemented it so far (e.g. with a
yaml dump) but when 50% of your facts require caching, it might be better to
let facter handle it centrally in one global caching file.
cheers,
Ohad
On Mon, Feb 2, 2009 at 2:41 AM, Paul Lathrop wrote:
>
> I don't think th
I don't think that belongs in facter; it belongs in the fact itself.
Just my .02
--Paul
On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe wrote:
>
> Oh and one other thing about 'facter.d' it'd be cool if there was some
> way to say that a given fact (or set of facts) is cache-able. Perhaps
> your fa
+1 for cached objects.
On Sun, Feb 1, 2009 at 3:18 PM, Sam Rowe wrote:
>
> Oh and one other thing about 'facter.d' it'd be cool if there was some
> way to say that a given fact (or set of facts) is cache-able. Perhaps
> your fact is resource intensive to discover and doesn't change much.
> It'd
Oh and one other thing about 'facter.d' it'd be cool if there was some
way to say that a given fact (or set of facts) is cache-able. Perhaps
your fact is resource intensive to discover and doesn't change much.
It'd be cool to have a built-in facility in facter that says "if you
just booted, find
I'm guessing this isn't the variety of feedback you're looking for,
but just in case:
We recently upgraded a couple of machines from facter 1.3.x to facter
1.5.x and were very dismayed to learn that $operatingsystemrelease on
Solaris had changed from the consistent-with-other-operatingsystems
"5.
> 2. Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
I'd vote for adding an optional output format to easily support shell
scripts:
Here is the shell compatible output of another tool I use:
set -A os_version_major "4"
set -A os_version_mi
Hi,
I have only developed an ip/interface fact that uses ip2 instead of
ifconfig. In order to detect multiple ip's per interface.
And my conclusion was that I really wanted some complexer data structures
and an easier integration with puppet.
jos
On 1/29/09 10:55 PM, "James Turnbull" wrote:
On Fri, Jan 30, 2009 at 6:58 AM, Ross McKerchar
wrote:
>
>
>
>> -Original Message-
>> From: puppet-users@googlegroups.com [mailto:puppet-
>> us...@googlegroups.com] On Behalf Of James Turnbull
>> Sent: 29 January 2009 21:55
>> To: puppet-users@googlegroups.com; puppet-...@googlegroups.com
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of James Turnbull
> Sent: 29 January 2009 21:55
> To: puppet-users@googlegroups.com; puppet-...@googlegroups.com
> Subject: [Puppet Users] Facter - the future - your input neede
On 30 Jan 2009, at 10:24, James Turnbull wrote:
> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
> network -> interface -> ipaddress.
I like this idea, but how would it work in both facter output (would
it force us to use a rich output format for instance?) and puppet
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Simpson wrote:
>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> YAML support is growing. .NET developers are starting to use YAML.
> I'd never choose XML output over other features. Maybe if an
Hi,
> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
> network -> interface -> ipaddress.
Sounds interesting.
> 2. Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
YAML support is growing. .NET developers are starting to use YAML.
I'd
Hello,
On 29.01.2009, at 22:55, James Turnbull wrote:
>
> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
> network -> interface -> ipaddress.
This would be a great thing to have. Additionally it would be cool to
have automatic true/false values for such namespaces, so:
ne
31 matches
Mail list logo
