On Tue, Feb 16, 2010 at 8:33 AM, Ohad Levy wrote:
> thats correct, foreman will import the facts as soon as they have been
> written to the yaml dir (or if you are using store config as soon as they
> are written to the db by puppet).
> in foreman deployment scenario, the first time puppet runs is
thats correct, foreman will import the facts as soon as they have been
written to the yaml dir (or if you are using store config as soon as they
are written to the db by puppet).
in foreman deployment scenario, the first time puppet runs is only to fetch
the certificates (e.g. in OS post install),
On Tue, Feb 16, 2010 at 8:19 AM, Ohad Levy wrote:
> probably dumb answer - use foreman as it includes the facts already ;)
but if I understand Foreman correctly, it's getting these from the
cached version server-side right? Either locally or as part of a task
from other puppet servers?
This mean
probably dumb answer - use foreman as it includes the facts already ;)
feature requests are welcomed
cheers,
Ohad
On Tue, Feb 16, 2010 at 5:51 PM, Nigel Kersten wrote:
> I'm going to ask what might be a dumb question now.
>
> Why can't we re-order things such that the external node classifier
>
I'm going to ask what might be a dumb question now.
Why can't we re-order things such that the external node classifier
doesn't simply get a certname as an argument, but instead receives all
the client facts?
There is an awful lot of logic I would like to remove from my
manifests and push to the
- "Dan Bode" wrote:
>> sure, but it just shows why global variables have been abandoned by
>> all but the most sucky devs and languages, puppet has some way to go
>> to make this easy for us to do the right thing :)
>
>
> I wish I had a better response for this point ;) Except I will say
>
On Mon, Feb 15, 2010 at 1:08 AM, Nat wrote:
>
> 3. forman and dashboard - there are not really feasible at the moment
>due to our current set up with our external node data store
>
Not sure if it helps, but foreman can import the data from your existing
external node tools:
http://theforeman.
Hi,
On Sun, Feb 14, 2010 at 5:38 PM, R.I.Pienaar wrote:
> hello,
>
> > with regards to scope, its possible that extlookup is more reliable
> > since it determines the value for the config inline, thus removing any
> > chance that a global variable assiged from the classifier would be
> > overrid
hello,
> with regards to scope, its possible that extlookup is more reliable
> since it determines the value for the config inline, thus removing any
> chance that a global variable assiged from the classifier would be
> overridden from an enclosing scope. This scoping issue for the
> external nod
Hi,
On Sun, Feb 14, 2010 at 3:31 PM, R.I.Pienaar wrote:
> hello,
>
> - "Nat" wrote:
>
> > 1. an external node classifier with variables passed in the
> > parameters section of the YAML to nodes.
> > 2. extlookup
>
> > My question is what is the conceptual difference between options
> > 1 an
hello,
- "Nat" wrote:
> 1. an external node classifier with variables passed in the
> parameters section of the YAML to nodes.
> 2. extlookup
> My question is what is the conceptual difference between options
> 1 and 2? is there differences between scope of variables defined
> either way?
Thanks for the advice so far.
We have looked at the following ideas for our implementation
1. an external node classifier with variables passed in the
parameters
section of the YAML to nodes.
2. extlookup
3. forman and dashboard - there are not really feasible at the moment
due to our cur
12 matches
Mail list logo
