RE: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.
That would be messy, given the Very Interesting way in things are separated, network-wise. It's probably a better long-term solution, but in the short term, setting up a data or config module and making r10K track it by branch looks to be the most viable solution. -- Robert Davidson > -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Rilindo Foster > Sent: Wednesday, September 28, 2016 8:44 PM > To: puppet-users@googlegroups.com > Subject: RE: [Puppet Users] R10K in an existing infrastructure OR How to > write yourself into a corner. > > Hi Robert! > > Is separating the customer data an option? That would let you manage the > modules without having to increment them constantly, while pulling the > customer data from another location - perhaps from a GIT repository using > Puppet's vcsrepo module. > > - Rilindo > > -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Robert Davidson > Sent: Wednesday, September 28, 2016 7:23 PM > To: 'puppet-users@googlegroups.com' > Subject: RE: [Puppet Users] R10K in an existing infrastructure OR How to > write yourself into a corner. > > I would prefer not to have to treat these modules any differently than the > rest - the only thing about the problem modules is that they include data > files that need to be pushed intact. Putting them into the control repo > would diverge them from the way we want to handle all other modules, > which strikes me as sub-optimal. I'm mostly looking to see if anyone else > has experience handling situations like this, and if they were able to come > up with a way to handle it without changing how modules are handled. > > One thing we did think about was to create a "data" module that contains > files like these, and are referred to inside r10K by branch rather than tag, > letting us continue to treat the bulk of the module correctly while isolating > our config files off to their own space. It's ugly, but could theoretically > work. > I can't help but feel that there must be a better way to do this, though. > > -- > Robert Davidson > > > > -Original Message- > > From: puppet-users@googlegroups.com [mailto:puppet- > > us...@googlegroups.com] On Behalf Of Rob Nelson > > Sent: Tuesday, September 27, 2016 4:52 PM > > To: puppet-users@googlegroups.com > > Subject: Re: [Puppet Users] R10K in an existing infrastructure OR How to > > write yourself into a corner. > > > > Have you looked at including these modules inside your r10k controlrepo? > > From a workflow perspective, that might be easier (branch, tweak files, > > PR/merge to `production`), though there may be issues surrounding access > > and permissions, of course. Have a gander at > > http://garylarizza.com/blog/2015/11/16/workflows-evolved-even- > besterer- > > practices/ for controlrepo theory and > > http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/ > > which details the conversion from modules in other repos to a > consolidated > > controlrepo. > > > > > > If access rights are an issue, you could have a standalone module that is > > pushed out by r10k via cron on a regular basis, across all repositories. See > > > https://github.com/puppetinabox/controlrepo/blob/production/Puppetfile > > #L51-L53 and > > > https://github.com/puppetinabox/controlrepo/blob/production/dist/profil > > e/manifests/puppet_master.pp#L25-L29 as an example of this. This would > > push the current version of that module to every environment that exists > at > > the time. I believe that if you specify a certain ref/branch inside an > > environment, it will deploy that ref/branch, otherwise it deploys the > > default branch of the repo, but would certainly verify that if you go down > > that road. > > > > > > > > Rob Nelson > > rnels...@gmail.com > > > > On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson > > wrote: > > > > > > We're still running puppet 3.6.2, and are finally getting around to > > trying to implement R10K. For assorted reasons, we have not been able to > > do this before now, and have a very large stack of home-grown modules > > that are all sitting in a monolithic repo. For the most part, it's been > > straightforward. We are splitting up the modules into their own repos, > > tagging them with version numbers, etc. But I've now hit an issue that's > got > > me blocked. > > > > We have several modules that i
RE: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.
I would prefer not to have to treat these modules any differently than the rest - the only thing about the problem modules is that they include data files that need to be pushed intact. Putting them into the control repo would diverge them from the way we want to handle all other modules, which strikes me as sub-optimal. I'm mostly looking to see if anyone else has experience handling situations like this, and if they were able to come up with a way to handle it without changing how modules are handled. One thing we did think about was to create a "data" module that contains files like these, and are referred to inside r10K by branch rather than tag, letting us continue to treat the bulk of the module correctly while isolating our config files off to their own space. It's ugly, but could theoretically work. I can't help but feel that there must be a better way to do this, though. -- Robert Davidson > -Original Message- > From: puppet-users@googlegroups.com [mailto:puppet- > us...@googlegroups.com] On Behalf Of Rob Nelson > Sent: Tuesday, September 27, 2016 4:52 PM > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] R10K in an existing infrastructure OR How to > write yourself into a corner. > > Have you looked at including these modules inside your r10k controlrepo? > From a workflow perspective, that might be easier (branch, tweak files, > PR/merge to `production`), though there may be issues surrounding access > and permissions, of course. Have a gander at > http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer- > practices/ for controlrepo theory and > http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/ > which details the conversion from modules in other repos to a consolidated > controlrepo. > > > If access rights are an issue, you could have a standalone module that is > pushed out by r10k via cron on a regular basis, across all repositories. See > https://github.com/puppetinabox/controlrepo/blob/production/Puppetfile > #L51-L53 and > https://github.com/puppetinabox/controlrepo/blob/production/dist/profil > e/manifests/puppet_master.pp#L25-L29 as an example of this. This would > push the current version of that module to every environment that exists at > the time. I believe that if you specify a certain ref/branch inside an > environment, it will deploy that ref/branch, otherwise it deploys the > default branch of the repo, but would certainly verify that if you go down > that road. > > > > Rob Nelson > rnels...@gmail.com > > On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson > wrote: > > > We're still running puppet 3.6.2, and are finally getting around to > trying to implement R10K. For assorted reasons, we have not been able to > do this before now, and have a very large stack of home-grown modules > that are all sitting in a monolithic repo. For the most part, it's been > straightforward. We are splitting up the modules into their own repos, > tagging them with version numbers, etc. But I've now hit an issue that's got > me blocked. > > We have several modules that include important data files inside > them. (Which is bad practice, I know, but many of these were written a > while ago and we're slowly working to refactor.) > In our current, monolithic setup, they reside in paths like this: > git/puppet/environments/production_ng/modules/$MODULE/files/ > customers/$FILENAME > > Each $FILENAME must be pushed out, with that name and it's > contents, to a particular directory on the machine using the module. The > files contain anywhere from ten to a hundred lines of config, varying per > customer. At the moment, we push them using a recursive file resource into > the directory. > > Under r10k, we want to use tags to mark version numbers and pull > them into environments. But these config files need to change rapidly, and > would result in ridiculous version creep if we increment every time we had > to adjust one of them. What is a good way to deal with data files like this > (ones where putting the contents into hiera is not really viable)? How do I > treat them under R10K? > > -- > Robert Davidson > > -- > You received this message because you are subscribed to the > Google Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to puppet-users+unsubscr...@googlegroups.com > <mailto:puppet-users%2bunsubscr...@googlegroups.com> . > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet- > users/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02 > <https:
[Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner.
We're still running puppet 3.6.2, and are finally getting around to trying to implement R10K. For assorted reasons, we have not been able to do this before now, and have a very large stack of home-grown modules that are all sitting in a monolithic repo. For the most part, it's been straightforward. We are splitting up the modules into their own repos, tagging them with version numbers, etc. But I've now hit an issue that's got me blocked. We have several modules that include important data files inside them. (Which is bad practice, I know, but many of these were written a while ago and we're slowly working to refactor.) In our current, monolithic setup, they reside in paths like this: git/puppet/environments/production_ng/modules/$MODULE/files/customers/$FILENAME Each $FILENAME must be pushed out, with that name and it's contents, to a particular directory on the machine using the module. The files contain anywhere from ten to a hundred lines of config, varying per customer. At the moment, we push them using a recursive file resource into the directory. Under r10k, we want to use tags to mark version numbers and pull them into environments. But these config files need to change rapidly, and would result in ridiculous version creep if we increment every time we had to adjust one of them. What is a good way to deal with data files like this (ones where putting the contents into hiera is not really viable)? How do I treat them under R10K? -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02. For more options, visit https://groups.google.com/d/optout.
RE: [Puppet Users] Catalog compilation weirdness
I think I figured it out.
The problem statement was
$domains = unique(delete_undef_values([ $admin_user_domain,
$admin_project_domain, $service_project_domain]))
keystone_domain { $domains:
ensure => present,
enabled => true,
}
For whatever reason, delete_undef_values wasn't doing what it said on the tin -
I'm not sure why, or if I should even report this as a bug to the
puppet-keystone devs. That looks like a valid bit of puppetry to me, and I have
no idea why it wasn't working on our setup.
--
Robert Davidson
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of Hristo Mohamed
> Sent: Sunday, February 28, 2016 2:54 PM
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] Catalog compilation weirdness
>
> I have seen the same type of error with a custom fact, that was failing to set
> the proper value for the variable(the variable was an array). Then the empty
> variable was used as a name for resource creation.
> Care to check for that in your manifests?
>
> Hristo
>
>
> On Feb 28, 2016 11:17 PM, "Robert Davidson"
> wrote:
>
>
> (This is under puppet 3.6.2.)
>
> In my ongoing monkey-knife-fight with the openstack puppet
> modules, I've run across a weird thing. I'm getting this error when I try to
> run
> puppet with a particular role:
> Error: Could not retrieve catalog from remote server: Could not
> intern from text/pson: Could not intern from data: Could not find
> relationship target "Keystone_domain[]"
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> Now, relationship errors usually mean that you're trying to define
> an empty resource, as I understand it. But the weird thing is that this is
> what
> I see on the puppet master:
> 2016-02-28 13:07:51 -0800 Puppet (info): Not using expired facts for
> $HOSTNAME from cache; expired at 2016-02-27 22:29:58 -0800
> 2016-02-28 13:07:51 -0800 Puppet (info): Caching facts for
> $HOSTNAME
> 2016-02-28 13:07:51 -0800 Puppet (info): Caching node for
> $HOSTNAME
> 2016-02-28 13:07:54 -0800 Puppet (info): 'replace facts' command for
> $HOSTNAME submitted to PuppetDB with UUID cc3dc352-e02c-440e-9684-
> 1d6ecc804b97
> 2016-02-28 13:07:55 -0800 Puppet (info): Caching node for
> $HOSTNAME
> 2016-02-28 13:08:01 -0800 Puppet (warning): Keystone under
> Eventlet has been deprecated during the Kilo cycle. Support for deploying
> under eventlet will be dropped as of the M-release of OpenStack.
> 2016-02-28 13:08:02 -0800 Puppet (warning): The version parameter
> is deprecated in Liberty.
> 2016-02-28 13:08:03 -0800 Puppet (notice): Compiled catalog for
> $HOSTNAME in environment development in 8.80 seconds
> 2016-02-28 13:08:03 -0800 Puppet (info): Caching catalog for
> $HOSTNAME
> 2016-02-28 13:08:05 -0800 Puppet (info): 'replace catalog' command
> for $HOSTNAME submitted to PuppetDB with UUID 8c6a8b88-86ef-4914-
> 9339-77b8caed8d3a
> 2016-02-28 13:08:08 -0800 Puppet (info): 'store report' command for
> $HOSTNAME submitted to PuppetDB with UUID adef58d0-ea93-47f6-a038-
> 14a279e972c1
>
> The master says it's successfully compiling a catalog, and thus giving
> me absolutely no useful information on where the problem is. As I'm trying
> to debug modules written by someone else, this is Not Helpful. Turning on
> debug output on the puppet master doesn't give me anything I can use
> either - is there some way to force it to spit out where this relationship
> problem is actually happening?
>
>
> --
> Robert Davidson
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to puppet-users+unsubscr...@googlegroups.com
> <mailto:puppet-users%2bunsubscr...@googlegroups.com> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-
> users/1EE73329D6577F44A3C2FB0F7D4ACAE98D08D178%40mbx-02.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-
> users/CALuoJ64u6Hjds%2Bf%
[Puppet Users] Catalog compilation weirdness
(This is under puppet 3.6.2.) In my ongoing monkey-knife-fight with the openstack puppet modules, I've run across a weird thing. I'm getting this error when I try to run puppet with a particular role: Error: Could not retrieve catalog from remote server: Could not intern from text/pson: Could not intern from data: Could not find relationship target "Keystone_domain[]" Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Now, relationship errors usually mean that you're trying to define an empty resource, as I understand it. But the weird thing is that this is what I see on the puppet master: 2016-02-28 13:07:51 -0800 Puppet (info): Not using expired facts for $HOSTNAME from cache; expired at 2016-02-27 22:29:58 -0800 2016-02-28 13:07:51 -0800 Puppet (info): Caching facts for $HOSTNAME 2016-02-28 13:07:51 -0800 Puppet (info): Caching node for $HOSTNAME 2016-02-28 13:07:54 -0800 Puppet (info): 'replace facts' command for $HOSTNAME submitted to PuppetDB with UUID cc3dc352-e02c-440e-9684-1d6ecc804b97 2016-02-28 13:07:55 -0800 Puppet (info): Caching node for $HOSTNAME 2016-02-28 13:08:01 -0800 Puppet (warning): Keystone under Eventlet has been deprecated during the Kilo cycle. Support for deploying under eventlet will be dropped as of the M-release of OpenStack. 2016-02-28 13:08:02 -0800 Puppet (warning): The version parameter is deprecated in Liberty. 2016-02-28 13:08:03 -0800 Puppet (notice): Compiled catalog for $HOSTNAME in environment development in 8.80 seconds 2016-02-28 13:08:03 -0800 Puppet (info): Caching catalog for $HOSTNAME 2016-02-28 13:08:05 -0800 Puppet (info): 'replace catalog' command for $HOSTNAME submitted to PuppetDB with UUID 8c6a8b88-86ef-4914-9339-77b8caed8d3a 2016-02-28 13:08:08 -0800 Puppet (info): 'store report' command for $HOSTNAME submitted to PuppetDB with UUID adef58d0-ea93-47f6-a038-14a279e972c1 The master says it's successfully compiling a catalog, and thus giving me absolutely no useful information on where the problem is. As I'm trying to debug modules written by someone else, this is Not Helpful. Turning on debug output on the puppet master doesn't give me anything I can use either - is there some way to force it to spit out where this relationship problem is actually happening? -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98D08D178%40mbx-02. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppetdb and multiple puppetmasters
I'm quite certain that there's something in the documentation that I'm missing here. (It has all the hallmarks of an Own Damn Fault situation.) Nonetheless, as I'm getting nowhere, I figure I'll fling out a cry for help. How do you configure puppetdb so it will permit multiple puppetmasters to talk to it? The only master that can successful submit facts/reports is the one that the puppetdb machine was puppeted from. All others get (hostnames stripped out, of course): Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for $HOSTNAME to PuppetDB at $PUPPETDBHOSTNAME:8081: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [unable to get local issuer certificate for /CN=$PUPPETDBHOSTNAME] What incredibly obvious thing have I overlooked entirely? -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98D08B812%40mbx-02. For more options, visit https://groups.google.com/d/optout.
RE: [Puppet Users] Re: Array of tags not applying to resource
So there's no way to apply more than one tag to something at a time and have it
actually act as if they are single tags?
Therefore, this exported resource:
@@module::hostentry{ $::fqdn:
tag => [$::fqdn, $::site],
}
Has these tags:
module
hostentry
module::hostentry
[$::fqdn, $::site]
Rather than what you might expect:
module
hostentry
module::hostentry
$::fqdn
$::site
That's . . . uh . . . special. I suppose I could get around this by only having
one tag added using the metaparameter, and include the other in the surrounding
class using the tag function, which would add them independently, but that's
ludicrous. (Is there any way to make puppet spit out the list of tags on a
resource in something like a notify{}? )
Given that I'm using an old version of puppet, would I be able to get anywhere
by filing a bug report on this behavior, or would it just get bitbucketed? I
don't see anything in the Puppet 4 docs that would indicate it's behavior has
changed, though.
--
Robert Davidson
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of jcbollinger
> Sent: Friday, August 07, 2015 5:59 AM
> To: Puppet Users
> Subject: [Puppet Users] Re: Array of tags not applying to resource
>
>
>
> On Thursday, August 6, 2015 at 5:39:40 PM UTC-5, robert.davidson wrote:
>
> First of all: I'm running puppet 3.6.2, as we are not in a position to
> move to Puppet 4 yet/
>
> When I try to apply an array of tags to an exported resource, as I
> should be able to according to docs
> (https://docs.puppetlabs.com/puppet/3.6/reference/lang_tags.html#the-
> tag-metaparameter
> <https://docs.puppetlabs.com/puppet/3.6/reference/lang_tags.html#the-
> tag-metaparameter> ), the tags simply do not apply, and thus collectors fail
> to function correctly. If I apply only a single tag, it works fine.
>
> This works:
> @@module::hostentry{ $::fqdn:
> tag => 'host.example.com',
> }
> Module::Hostentry <<| tag != 'host.example.com' |>>
>
> This does not - fails with duplicate resource errors, because we
> already have a host entry for the machine defined elsewhere:
> @@module::hostentry{ $::fqdn:
> tag => ['host.example.com'],
> }
> Module::Hostentry <<| tag != 'host.example.com' |>>
>
>
> My actual code is trying to use more than one tag, and looks more
> like this, which again, works if I cut it down to a single tag on the
> resource:
>
> @@module::hostentry{ $::fqdn:
> tag => [$::fqdn, $::site],
> }
> Module::Hostentry <<| tag ==$::site and tag != $::fqdn|>>
>
>
> I must be doing *something* wrong here, since I haven't been able
> to turn up anyone else complaining about this, and something that is so
> contrary to what the documentation says would surely have hit someone
> else before now!
>
>
>
>
>
> Per the docs
> <https://docs.puppetlabs.com/puppet/3.6/reference/lang_collectors.html#
> search-expressions> , there is a bit of asymmetry between the '==' and '!='
> operators in search expressions:
>
>
> * For ==, "this operator will match if the value of the attribute (or one
> of the value’s members, if the value is an array) is identical to the search
> key."
> * For !=, "This operator will always match if the attribute’s value is an
> array."
>
> Both behaviors make sense (in particular, a scalar value certainly isn't equal
> to any array), but they are not proper opposites of each other with respect
> to arrays, as one might reasonably expect them to be.
>
>
> John
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/878a121c-05ab-4a78-
> b2ab-f63bc4633341%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/878a121c-05ab-4a78-
> b2ab-
> f63bc4633341%40googlegroups.com?utm_medium=email&utm_source=foot
> er> .
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CF462CA%40mbx-02.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Array of tags not applying to resource
First of all: I'm running puppet 3.6.2, as we are not in a position to move to
Puppet 4 yet/
When I try to apply an array of tags to an exported resource, as I should be
able to according to docs
(https://docs.puppetlabs.com/puppet/3.6/reference/lang_tags.html#the-tag-metaparameter),
the tags simply do not apply, and thus collectors fail to function correctly.
If I apply only a single tag, it works fine.
This works:
@@module::hostentry{ $::fqdn:
tag => 'host.example.com',
}
Module::Hostentry <<| tag != 'host.example.com' |>>
This does not - fails with duplicate resource errors, because we already have a
host entry for the machine defined elsewhere:
@@module::hostentry{ $::fqdn:
tag => ['host.example.com'],
}
Module::Hostentry <<| tag != 'host.example.com' |>>
My actual code is trying to use more than one tag, and looks more like this,
which again, works if I cut it down to a single tag on the resource:
@@module::hostentry{ $::fqdn:
tag => [$::fqdn, $::site],
}
Module::Hostentry <<| tag ==$::site and tag != $::fqdn|>>
I must be doing *something* wrong here, since I haven't been able to turn up
anyone else complaining about this, and something that is so contrary to what
the documentation says would surely have hit someone else before now!
--
Robert Davidson
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CF452F3%40mbx-02.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Virtual resources, collectors, and overrides.
When collecting virtual resources, is there a way to override them to *remove* specific attributes? For example, I have a set of service definitions with requires, and I want to collect them without those. (It's rather more complicated than that, but illustrates what I want to do.) Is this even possible? I haven't found a way yet. -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CF32299%40mbx-02. For more options, visit https://groups.google.com/d/optout.
RE: [Puppet Users] Stupid hiera.yaml wildcard question.
On Tuesday, June 02, 2015 at 12:55 AM, jamese sent:
> If you use calling_class as part of the hierarchy in your hiera.yaml file, you
> can have files named after the calling class.
>
> https://docs.puppetlabs.com/hiera/1/puppet.html#special-pseudo-
> variables
>
> This would allow you to create a yaml file named after each class in
> question.
>
> You can also use calling_module, but that probably wouldn't give the
> granularity that you want.
Hmm. That had been something that I looked at, but this bit in the
documentation:
"Note that these variables are effectively local scope, as they are
pseudo-variables that only exist within the context of a specific class, and
only inside of hiera. Therefore, they must be called as %{variable_name} and
never %{::variable_name}. They are not top-scope."
Followed by:
"Do not use local Puppet variables in Hiera’s hierarchy or data sources. Only
use facts and ENC-set top-scope variables."
Led me to discard them as useful in constructing a hiera.yaml hierarchy. From
your response (and the replies from Craig and John) it appears that I was
incorrect to do so. Thanks!
--
Robert Davidson
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CEFA274%40mbx-02.
For more options, visit https://groups.google.com/d/optout.
RE: [Puppet Users] Stupid hiera.yaml wildcard question.
On Monday, June 01, 2015 at 1:48 PM, Christopher Wood said: *snip* > It sounds like more pain than it's worth, figuring out which hiera key to use > in two dimensions of lookup instead of one. It wouldn't be two dimensions, though. As it currently stands, my profile.yaml file contains keys that look like so: # Logrotate Profile profile::logrotate::package::present: 'logrotate': 'ensure': 'present' profile::logrotate::serviceconf: "/etc/logrotate.conf" profile::logrotate::servicefile: "logrotate.conf" profile::logrotate::cronloc: "/etc/cron.daily/logrotate" profile::logrotate::cronfile: "logrotate.cron" # NTP Profile profile::ntp::servicename: "ntpd" profile::ntp::serviceconf: "/etc/ntp.conf" profile::ntp::servicefile: "ntp.conf" profile::ntp::package::present: 'ntp': 'ensure': 'present' 'ntpdate': 'ensure': 'present' . . . with a whole bunch more profile::$MODULE::$KEY entries for other profile modules following that. (We're making an extremely concerted effort to minimize the amount of data built into our modules, due to past experience with how much of a pain in the ass that becomes.) What I would rather have is a profile directory in my hiera.yaml, where all the files there are loaded automatically by hiera, so I can have profile/logrotate.yaml with the logrotate keys, profile/ntp.yaml with ntp related keys, and so on down the line. This would make it simpler to keep things clear between different modules when setting the assorted defaults. Unless there's a dead simple way to set a fact that will load a a yaml associated with each assigned class, which would make everything so much easier. . . -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CEE328F%40MBX-02.WIN.NOMINUM.COM. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Stupid hiera.yaml wildcard question.
Note: We're still running puppet 3.6.2 and hiera 1.3. What I would like to do is to have hiera load all yaml files inside a directory - ie, have all the profile specific data split up into independent files sitting inside a 'profile' directory, without having to tell hiera to load them individually. This would purely be for ease of working with data for each profile module, rather than having all data changes committed against a single profile.yaml file. Is that a thing that can be done? I don't see a way to do it, but it seems so staggeringly obvious a thing to want to do that I'm sure I'm missing something. -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CEE3058%40MBX-02.WIN.NOMINUM.COM. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Virtual users and group gids
When creating users from hiera, it's simple enough to make them all virtual using create_resources and then realize them. This does leave me with a question, though. How do I make sure that the assorted groups associated with each user are created with the proper gid? I don't see any easy way to define "If this group is created, use this gid" in puppet. Am I missing something? -- Robert Davidson -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1EE73329D6577F44A3C2FB0F7D4ACAE98CC1A914%40MBX-02.WIN.NOMINUM.COM. For more options, visit https://groups.google.com/d/optout.
