Possible to overriding Hiera on the run-time?

365 views
Skip to first unread message

Sans

unread,
Sep 16, 2015, 12:39:32 PM9/16/15
to Puppet Users
Hi there,

I got to solve a "rare" issue here which I'm running out of ideas for. In our manifest, we do some conditional  git pull (using vcsrepo forgemodule) based on a Hiera variable that set either true or false. We keep the value as false i.e. no git-pull by default but want to set it true, on the fly temporarily for onetime run. Is there anyway to override hiera value when running puppet agent from the command-line on the run-time?

Generally, we run on-demand puppet agent using mcollective, like this: mco puppet runonce -I <node_name>
Is there anywhay to achieve the same using mCollective at all? Or what other options do I have?

Any suggestions/pointer will be greatly appreciated.

-San

jcbollinger

unread,
Sep 17, 2015, 1:00:41 PM9/17/15
to Puppet Users
It's unclear from where you want to control this one-off behavior alteration.  If from the target node, then you want to rely on a custom fact.  There are several ways to write a fact whose value you can easily influence at run time, and there are many ways you can condition the declarations in your manifests and the data retrieved from Hiera on the value of a given fact.


John

Craig Dunn

unread,
Sep 17, 2015, 1:55:23 PM9/17/15
to puppet...@googlegroups.com
On Thu, Sep 17, 2015 at 3:00 PM, jcbollinger <John.Bo...@stjude.org> wrote:
>
>
> On Wednesday, September 16, 2015 at 7:39:32 AM UTC-5, Sans wrote:
>>
>> Hi there,
>>
>> I got to solve a "rare" issue here which I'm running out of ideas for. In
>> our manifest, we do some conditional git pull (using vcsrepo forgemodule)
>> based on a Hiera variable that set either true or false. We keep the value
>> as false i.e. no git-pull by default but want to set it true, on the fly
>> temporarily for onetime run. Is there anyway to override hiera value when
>> running puppet agent from the command-line on the run-time?
[snip]
>
>
> It's unclear from where you want to control this one-off behavior
> alteration. If from the target node, then you want to rely on a custom
> fact. There are several ways to write a fact whose value you can easily
> influence at run time, and there are many ways you can condition the
> declarations in your manifests and the data retrieved from Hiera on the
> value of a given fact.

It's can be done easier than that, although facts is the right
track... You don't actually have to create a fact, you could just
test for the existence of it...

class mything (
$pull_repo, # sourced from hiera mything::pull_repo
) {

$do_pull = $::pull_repo ? {
undef => $pull_repo,
default => $::pull_repo,
}
}

Note the use of top level scoping there - by default $::pull_repo will
be undef and the value from hiera used, you can then dynamically
create your fact on the fly by calling puppet agent with...

FACTER_pull_repo=yes puppet agent -t

Im not sure how you would tie that into the mcollective job, but it
shouldn't be too hard....

Craig

--
Enviatics | Automation and configuration management
http://www.enviatics.com | @Enviatics
Puppet Training http://www.enviatics.com/training/

Sans

unread,
Sep 17, 2015, 8:55:30 PM9/17/15
to Puppet Users
Thanks Craig!
I will give it a go tonight and report here back.

-S
Reply all
Reply to author
Forward
0 new messages