[Puppet Users] puppetlabs apt - norecommend option
Hello, I would like to use the apt module, but I can't set this preference (If I am not wrong) : /etc/apt.conf.d/01norecommend > > # apt : FILE MANAGED BY PUPPET > > APT::Install-Recommends "0"; > > APT::Install-Suggests "0"; > Does anyone have an idea on how to implement this via this plugin ? Best regards, -- 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/9c30fdf3-06d1-40b6-b1e0-4cb074e57488%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetlabs apt - norecommend option
On Thu, Feb 2, 2017, at 09:13, Romgo wrote: > Hello, > > > I would like to use the apt module, but I can't set this preference (If I > am not wrong) : > > /etc/apt.conf.d/01norecommend > > > > # apt : FILE MANAGED BY PUPPET > > > > APT::Install-Recommends "0"; > > > > APT::Install-Suggests "0"; > > > > Does anyone have an idea on how to implement this via this plugin ? > > Best regards, why don't you just use a file resource? It's not required for every possible feature ever to exist in every module, you can easily augment them. -- R.I.Pienaar / www.devco.net / @ripienaar -- 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/1486023600.1488019.867723928.1022ACAD%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetlabs apt - norecommend option
Hello, I can, but in this case if there is a new release for the pluggins I'll have to change the code again. It is better to have this option built-in. Le jeudi 2 février 2017 09:20:09 UTC+1, R.I. Pienaar a écrit : > > > > On Thu, Feb 2, 2017, at 09:13, Romgo wrote: > > Hello, > > > > > > I would like to use the apt module, but I can't set this preference (If > I > > am not wrong) : > > > > /etc/apt.conf.d/01norecommend > > > > > > # apt : FILE MANAGED BY PUPPET > > > > > > APT::Install-Recommends "0"; > > > > > > APT::Install-Suggests "0"; > > > > > > > Does anyone have an idea on how to implement this via this plugin ? > > > > Best regards, > > why don't you just use a file resource? It's not required for every > possible feature ever to exist in every module, you can easily augment > them. > > > -- > R.I.Pienaar / www.devco.net / @ripienaar > -- 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/c96e8360-a32f-44ea-8e02-815ee9917256%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] drop-down list for class parameter values
Is there a way to define a list of allowed values for a class parameter so that it shows up as a drop-down menu in pe-console? If not, would this be a feasible feature to add? Have a common case where a parameter is a few set possible values, would like to make it easy to 'select' one. Thanks, James -- 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/87cf8470-953d-4362-8efa-f38171e5cf48%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Help with data structure
Hi folks,
I'm grappling with a data structure that I want to model as a hash in
Puppet and ultimately mash it down to a string for use in a config file.
I'm writing out a config for Nagios BPI and there is one complex
parameter "members" which is described like this in the documentation:
# members - a comma delineated list of members.
#For services, format is: ;;,
#For groups, format is: $;,
#the is an '&' or '|' character.
#'&' option after host:servicename means service is part of a
CLUSTER
#For clusters, 'critical' is only reached when ALL services in a
cluster are NOT 'Ok'
# '|' option after host:servicename means it is an essential
service for the group,
# example: a 'critical' service with an '|' option will cause a
'critical' state
# for the entire group.
When configured, the parameter looks like this:
members=radius-local01.example.com;RADIUS;&,
radius-local02.example.com;RADIUS;&, radius-local03.example.com;RADIUS;&,
I want to model this in a hash like this:
$members = {
'radius-local01.example.com' => {
service => 'RADIUS',
opt => '&',
},
'radius-local02.example.com' => {
service => 'RADIUS',
opt => '&',
},
'radius-local03.example.com' => {
service => 'RADIUS',
opt => '&',
},
}
Is my design sensible, and how can I manipulate this data to generate a
string in the config file as above? I'm using Puppet Enterprise 2016.5
but I only upgraded from Puppet 3.8 a couple of weeks ago, so I'm still
new to the Puppet 4 syntax.
Thanks,
Jonathan
--
Jonathan Gazeley
Senior Systems Administrator
IT Services
University of Bristol
--
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/7794f367-7028-0bb5-422c-2d46bc133545%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet stop working
Hi, We just update puppet-agent (Debian, puppetlabs repot) on the puppetserver (last version), and every agent stop working with this error Info: Using configured environment 'jas' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: hiera configuration version 3 cannot be used in an environment on node node_fqdn Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Anyone have this problem ? Any idea ? Regards JAS -- Albert SHIH DIO bātiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France xmpp: j...@obspm.fr Heure local/Local time: jeu 2 fév 2017 14:26:45 CET -- 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/20170202132817.GA48142%40pcjas.obspm.fr. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [Puppet-dev] Draft for new type and provider API
On 2 February 2017 at 02:50, Trevor Vaughan wrote: > Hi David, > > Most of this looks fine (I still need to digest some of it) but I don't > know that I'm a huge fan of no munge or validate functionality. This seems > to fly in the face of a 'fail fast' mentality. > With puppet 4 data types much of the trivial stuff munge and validate do can be handled much easier and consistently than before. Many other checks will never be possible on the server, because they depend on values only available on the agent (credential validity, max tablename length dependent on mysql flavour), or would be error prone duplication of things the target API does check for us (validity of file mode bit combinations, validity of AMI references when talking to EC2 instances, etc). There is a bit of stuff in-between those two (e.g. content&source specified on a file), which we'd trade-off for a much simpler server side. Failing on the agent, also means that independent parts of the catalog can move forward, instead of failing the whole compilation. > Also, if everything happens on the client, some of the catalog munging > that I do on the fly isn't going to work any longer. > Those resources will not look anything different than existing types (which will stay as they are for a considerable while). Since I don't know what catalog munging you're doing I'm having a hard time following here. I *do* like the idea of types being pure data but will this bloat the > catalog even further? > The resources in the catalog won't look any different than today. In fact, the first version will most likely just call Puppet::Type.newtype() under the hood somewhere. > I still think that moving toward a heap/stack model would serve the Puppet > clients best and get past the resource count limitations. > Do you have those ideas written up somewhere? > Fundamentally, I want my clients to do as little work as possible since > they're meant to be running business processes. > Same. > > I'll definitely be keeping an eye on this conversation though. > > Thanks, > Thanks for your time and work you're putting in here. David > > Trevor > > On Tue, Jan 31, 2017 at 11:04 AM, David Schmitt > wrote: > >> Hi *, >> >> The type and provider API has been the bane of my existence since I >> [started writing native resources](https://github.com/ >> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2). >> Now, finally, we'll do something about it. I'm currently working on >> designing a nicer API for types and providers. My primary goals are to >> provide a smooth and simple ruby developer experience for both scripters >> and coders. Secondary goals were to eliminate server side code, and make >> puppet 4 data types available. Currently this is completely aspirational >> (i.e. no real code has been written), but early private feedback was >> encouraging. >> >> To showcase my vision, this [gist](https://gist.github.com >> /DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the [apt_key type]( >> https://github.com/puppetlabs/puppetlabs-apt/blob/ >> master/lib/puppet/type/apt_key.rb) and [provider](https://github.com/ >> puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/ >> apt_key/apt_key.rb) ported over to my proposal. The second example there >> is a more long-term teaser on what would become possible with such an API. >> >> The new API, like the existing, has two parts: the implementation that >> interacts with the actual resources, a.k.a. the provider, and information >> about what the implementation is all about. Due to the different usage >> patterns of the two parts, they need to be passed to puppet in two >> different calls: >> >> The `Puppet::SimpleResource.implement()` call receives the >> `current_state = get()` and `set(current_state, target_state, noop)` >> methods. `get` returns a list of discovered resources, while `set` takes >> the target state and enforces those goals on the subject. There is only a >> single (ruby) object throughout an agent run, that can easily do caching >> and what ever else is required for a good functioning of the provider. The >> state descriptions passed around are simple lists of key/value hashes >> describing resources. This will allow the implementation wide latitude in >> how to organise itself for simplicity and efficiency. >> >> The `Puppet::SimpleResource.define()` call provides a data-only >> description of the Type. This is all that is needed on the server side to >> compile a manifest. Thanks to puppet 4 data type checking, this will >> already be much more strict (with less effort) than possible with the >> current APIs, while providing more automatically readable documentation >> about the meaning of the attributes. >> >> >> Details in no particular order: >> >> * All of this should fit on any unmodified puppet4 installation. It is >> completely additive and optional. Currently. >> >> * The Type definition >> * It is data-only. >> * Refers to puppet data types. >> * N
Re: [Puppet Users] puppet stop working
Le 02/02/2017 à 14:28:17+0100, Albert Shih a écrit > Hi, > > We just update puppet-agent (Debian, puppetlabs repot) on the puppetserver > (last version), and every agent stop working with this error > > > Info: Using configured environment 'jas' > Info: Retrieving pluginfacts > Info: Retrieving plugin > Info: Loading facts > Error: Could not retrieve catalog from remote server: Error 500 on SERVER: > Server Error: hiera configuration version 3 cannot be used in an environment > on node node_fqdn > Warning: Not using cache on failed catalog > Error: Could not retrieve catalog; skipping run > > > Anyone have this problem ? It's seem it's because the apt-get upgrade install the new-futur version of puppet-agent 1.9.0 and come with new hiera module. So don't upgrade you puppet-agent until official annoncement (something I always shoud do...) > > Any idea ? To solve the problem go back with the previous version (1.8.x) restart the puppetserver. Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France xmpp: j...@obspm.fr Heure local/Local time: jeu 2 fév 2017 15:31:15 CET -- 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/20170202143255.GB48142%40pcjas.obspm.fr. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppetlabs apt - norecommend option
Hello,
I found the way to do it with this module :
create a norecommend.erb file in templates folder of apt module and then
add :
apt::setting { "conf-norecommend":
content => template('apt/norecommend.erb'),
ensure => present,
}
regards,
Le jeudi 2 février 2017 09:30:32 UTC+1, Romgo a écrit :
>
> Hello,
>
> I can, but in this case if there is a new release for the pluggins I'll
> have to change the code again.
> It is better to have this option built-in.
>
>
>
> Le jeudi 2 février 2017 09:20:09 UTC+1, R.I. Pienaar a écrit :
>>
>>
>>
>> On Thu, Feb 2, 2017, at 09:13, Romgo wrote:
>> > Hello,
>> >
>> >
>> > I would like to use the apt module, but I can't set this preference (If
>> I
>> > am not wrong) :
>> >
>> > /etc/apt.conf.d/01norecommend
>> > >
>> > > # apt : FILE MANAGED BY PUPPET
>> > >
>> > > APT::Install-Recommends "0";
>> > >
>> > > APT::Install-Suggests "0";
>> > >
>> >
>> > Does anyone have an idea on how to implement this via this plugin ?
>> >
>> > Best regards,
>>
>> why don't you just use a file resource? It's not required for every
>> possible feature ever to exist in every module, you can easily augment
>> them.
>>
>>
>> --
>> R.I.Pienaar / www.devco.net / @ripienaar
>>
>
--
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/46180055-3d96-4a8f-bf13-dada02431513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [Puppet-dev] Draft for new type and provider API
I think I'm slowly talking myself into this. The issue that I've had is that the current Data Types are composable. There's a ticket open about it and hopefully that will fix a lot of my issues. Unfortunately, it looks like my heap/stack discussion was with Henrik on Slack, so that's not super helpful. Basically, the idea is that, instead of using a pure object model, objects would be created *as necessary* and the linear execution model would be kept in a simple array (stack). The data space (heap) would contain the attributes that are required for each object to execute. This means that the data structure would be extremely efficient and there would be almost no cost to building and manipulating an object graph. The benefit of the object graph is to keep the object model. However, the object model is simply not necessary and has proven not to scale to 10k+ resources. The Heap/Stack model should scale based on the amount of data that you have and would be *extremely* portable to other languages. The biggest down side (for me) is that I manipulate the catalog graph at run time for various reasons. There would probably be an easy way to work this into the API though since it would just be an array insertion. In terms of the validate/munge question, munging can *absolutely* be done client side. But do you even want to pass a catalog to the client if you have invalid data that might be used by other resources. Also, I do quite a bit of checking based on the values of other parameters/properties. If this could be maintained reasonably, that would be fine. I do think that having a global data space would be extremely important to making this feasible. There are a couple of tickets on for this as well but I don't know the numbers off hand. And, of course, if we use the heap/stack model, the data is all in place (but may change based on resource processing). Hopefully this all makes sense. Thanks, Trevor On Thu, Feb 2, 2017 at 8:42 AM, David Schmitt wrote: > > > On 2 February 2017 at 02:50, Trevor Vaughan > wrote: > >> Hi David, >> >> Most of this looks fine (I still need to digest some of it) but I don't >> know that I'm a huge fan of no munge or validate functionality. This seems >> to fly in the face of a 'fail fast' mentality. >> > > With puppet 4 data types much of the trivial stuff munge and validate do > can be handled much easier and consistently than before. Many other checks > will never be possible on the server, because they depend on values only > available on the agent (credential validity, max tablename length dependent > on mysql flavour), or would be error prone duplication of things the target > API does check for us (validity of file mode bit combinations, validity of > AMI references when talking to EC2 instances, etc). There is a bit of stuff > in-between those two (e.g. content&source specified on a file), which we'd > trade-off for a much simpler server side. Failing on the agent, also means > that independent parts of the catalog can move forward, instead of failing > the whole compilation. > > >> Also, if everything happens on the client, some of the catalog munging >> that I do on the fly isn't going to work any longer. >> > > Those resources will not look anything different than existing types > (which will stay as they are for a considerable while). Since I don't know > what catalog munging you're doing I'm having a hard time following here. > > I *do* like the idea of types being pure data but will this bloat the >> catalog even further? >> > > The resources in the catalog won't look any different than today. In fact, > the first version will most likely just call Puppet::Type.newtype() under > the hood somewhere. > > >> I still think that moving toward a heap/stack model would serve the >> Puppet clients best and get past the resource count limitations. >> > > Do you have those ideas written up somewhere? > > >> Fundamentally, I want my clients to do as little work as possible since >> they're meant to be running business processes. >> > > Same. > > >> >> I'll definitely be keeping an eye on this conversation though. >> >> Thanks, >> > > Thanks for your time and work you're putting in here. > > > David > > >> >> Trevor >> >> On Tue, Jan 31, 2017 at 11:04 AM, David Schmitt > > wrote: >> >>> Hi *, >>> >>> The type and provider API has been the bane of my existence since I >>> [started writing native resources](https://github.com/ >>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2). >>> Now, finally, we'll do something about it. I'm currently working on >>> designing a nicer API for types and providers. My primary goals are to >>> provide a smooth and simple ruby developer experience for both scripters >>> and coders. Secondary goals were to eliminate server side code, and make >>> puppet 4 data types available. Currently this is completely aspirational >>> (i.e. no real code has been written), but early private feedback was >>> encouraging. >>> >
[Puppet Users] having hiera issues after upgrade to Puppet 4.9.0 ?
Puppet 4.9.0 just went live and we are waiting for the proper release notes to be sent out. Early users have started to upgrade and have been running into a couple of issues that are easily fixable. The new implementation is sensitive to errors in hiera.yaml If you see a "expected Hash, got Boolean", or "expected Hash got String", it is most likely because your hiera.yaml file is empty. If you want it to be empty, modify it to have an empty :hierarhy hash instead. Or move it out of the way and get the defaults. There will be an improvement in PUP 4.9.1 where an empty hiera.yaml will not error in this way. See Jira ticket PUP-7164). The new implementation reads and uses a hiera.yaml in the root of an environment. -- If you get the error "a hiera.yaml version 3 cannot be used in an environment" means that puppet found a hiera.yaml in the root of an environment, and that is taken as an opt in to hiera 5's "data in environment" feature. For example, you may have .../environments/production/hiera.yaml That file used to have no meaning (just being a copy placed there). It is now significant. Fix the issue by moving it out of the way (rename, or delete). Those that use this pattern to symlink to the real global hiera.yaml need to rethink if they want to continue doing so. The real solution is to use the features in hiera 5 and actually keep the configuration in the environment. - henrik -- Visit my Blog "Puppet on the Edge" http://puppet-on-the-edge.blogspot.se/ -- 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/o6vksi%24ho6%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: [Puppet-dev] Draft for new type and provider API
On 2 February 2017 at 15:38, Trevor Vaughan wrote: > I think I'm slowly talking myself into this. > > The issue that I've had is that the current Data Types are composable. > There's a ticket open about it and hopefully that will fix a lot of my > issues. > Assuming you're talking about PUP-7033, there is nothing much I can help you with there. > Unfortunately, it looks like my heap/stack discussion was with Henrik on > Slack, so that's not super helpful. > > Basically, the idea is that, instead of using a pure object model, objects > would be created *as necessary* and the linear execution model would be > kept in a simple array (stack). The data space (heap) would contain the > attributes that are required for each object to execute. > > This means that the data structure would be extremely efficient and there > would be almost no cost to building and manipulating an object graph. > > The benefit of the object graph is to keep the object model. However, the > object model is simply not necessary and has proven not to scale to 10k+ > resources. The Heap/Stack model should scale based on the amount of data > that you have and would be *extremely* portable to other languages. > The agent requires the whole graph for its operation. Since the v1 of this will only build on top of the existing APIs, I expect the (memory) situation to get worse before it'll get better. The new API itself doesn't need a huge object model for its operation. The resources are passed around as simple arrays and hashes. That could be much more compact than the current glut of Puppet::Provider instances. > The biggest down side (for me) is that I manipulate the catalog graph at > run time for various reasons. There would probably be an easy way to work > this into the API though since it would just be an array insertion. > Yeah, things like file#recurse, or what concat_file does with `generate` would not be possible with this new API. That is a deliberate decision to skip a complex fringe feature. I'd love to see what you're doing with it, to get a better handle of how to re-introduce this in a more pleasant form. Within the next few years, you'll still be able to just use the puppet 2 T&P API as-is, if you need to. > In terms of the validate/munge question, munging can *absolutely* be done > client side. But do you even want to pass a catalog to the client if you > have invalid data that might be used by other resources. Also, I do quite a > bit of checking based on the values of other parameters/properties. If this > could be maintained reasonably, that would be fine. > The hard and generic case of error handling is dynamic errors during application of the catalog. Puppet will always have to deal with those gracefully. Are there some validations that could be done earlier than during the update? Absolutely. How much does it buy us, though? If you have pointers to cool things you're currently doing, I'd be very interested in seeing those. No worries about timing. Due to travels, this proposal won't go anywhere in the next two weeks. And I'd rather have the full picture anyways. > I do think that having a global data space would be extremely important to > making this feasible. There are a couple of tickets on for this as well but > I don't know the numbers off hand. And, of course, if we use the heap/stack > model, the data is all in place (but may change based on resource > processing). > Having a proper place to do global transformations on the catalog both agent and server side would be beneficial to many advanced use-cases. As I said above, the current way to do so will not go away anytime soon. This Resource API just won't make it any less painful. > > Hopefully this all makes sense. > Very much so. I hope the same. Cheers, David > Thanks, > > Trevor > > On Thu, Feb 2, 2017 at 8:42 AM, David Schmitt > wrote: > >> >> >> On 2 February 2017 at 02:50, Trevor Vaughan >> wrote: >> >>> Hi David, >>> >>> Most of this looks fine (I still need to digest some of it) but I don't >>> know that I'm a huge fan of no munge or validate functionality. This seems >>> to fly in the face of a 'fail fast' mentality. >>> >> >> With puppet 4 data types much of the trivial stuff munge and validate do >> can be handled much easier and consistently than before. Many other checks >> will never be possible on the server, because they depend on values only >> available on the agent (credential validity, max tablename length dependent >> on mysql flavour), or would be error prone duplication of things the target >> API does check for us (validity of file mode bit combinations, validity of >> AMI references when talking to EC2 instances, etc). There is a bit of stuff >> in-between those two (e.g. content&source specified on a file), which we'd >> trade-off for a much simpler server side. Failing on the agent, also means >> that independent parts of the catalog can move forward, instead of failing >> the whole compilation. >> >> >>> Also
Re: [Puppet Users] Draft for new type and provider API
Serious question:
> Puppet::SimpleResource.implement('apt_key')
What is the benefit of a construct like this compared to a regular ruby
class where it will be completely obvious to every ruby programmer how
inheritance works and what actually happens if I use a mixin?
--
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/02b47796-0b7c-3d89-db70-414201dd64e4%40puzzle.ch.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] drop-down list for class parameter values
On 02/02/17 00:46, James Boone wrote:
Is there a way to define a list of allowed values for a class parameter
so that it shows up as a drop-down menu in pe-console?
If not, would this be a feasible feature to add?
Have a common case where a parameter is a few set possible values, would
like to make it easy to 'select' one.
The first part, making sure that the allowed values for a class
parameter are declared is simply done with the puppet type system
class example(Enum[red, blue, green] $color) { ... }
The type information should be available to the pe services that queries
for all classes and their parameters. The question is what it
(pe-console) can do with that information.
It gets somewhat complicated in that the types may be something other
than a simple enumeration and the logic added to pe-console would
naturally need to handle those cases gracefully. The type information
may also be based on custom types, and those will require loading of
those to fully understand what they mean. This because a definition like
this:
type PrimaryColor = Enum[red, blue, green]
can be autoloaded, and the class parameter could be declared like this:
class example(PrimaryColor $color) { ... }
One alternative way of implementing that in pe-console is to have the
service precompute those cases where value is a simple "multiple choice"
- that may have a performance impact though as it would require
computing it for all parameters in every class.
Another way would be to have a service that for a given environment an
answer if a parameter's type results in a static "multiple choice".
yet another way would be to have a service that validates what the user
entered against the type. The error message would state what the valid
options are, or where it went wrong. Something like this would then
also handle types that are based on patterns.
Hope that provides you with some ideas.
Best,
- henrik
Thanks,
James
--
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/87cf8470-953d-4362-8efa-f38171e5cf48%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/o6vmq2%24a6u%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] puppet stop working
On 02/02/17 14:28, Albert Shih wrote: Hi, We just update puppet-agent (Debian, puppetlabs repot) on the puppetserver (last version), and every agent stop working with this error Info: Using configured environment 'jas' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: hiera configuration version 3 cannot be used in an environment on node node_fqdn Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run Anyone have this problem ? Any idea ? You have a hiera.yaml in the root of your environment. It should not be there. Rename it or move it out of the way. Best, - henrik -- Visit my Blog "Puppet on the Edge" http://puppet-on-the-edge.blogspot.se/ -- 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/o6vp50%24qn8%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Announce: puppet-agent 1.9.0 released!
Hi All, I’m excited to announce the release of Puppet Agent 1.9.0, which includes Puppet 4.9.0. There’s lots of good stuff in this release, but a few highlights include: • Hiera 5 - a successor of the experimental Puppet lookup feature - is built into Puppet 4.9. This allows you to have Hiera data embedded in modules as well as per-environment hierarchies, provides an "explain" feature for easy debugging, and has significant performance improvements. Read more here: https://docs.puppet.com/puppet/latest/lookup_quick.html • Fixes for several bugs related to Unicode and UTF-8 support in Puppet. • New fact: `cloud`. This new top-level fact is intended for discovering whether a node is running on a given public cloud provider. In this first release, it currently detects whether a Linux-based node is running in Azure, and provides that information in the cloud.provider fact. Deprecations in this release include deprecations of several Puppet faces, as well as Puppet support for the Ruby 2.0 series. For a complete list of Puppet 4.9.0 features, bug fixes, and deprecations, please see the release notes at https://docs.puppet.com/puppet/4.9/release_notes.html. Special thanks to community member Shawn Ferry for contributing several fixes for Puppet on Solaris. Two caveats: In Puppet 4.9.0, we removed the vendored `semantic` gem, replacing it with `semantic_puppet`. We learned this causes an issue with any module based on https://github.com/garethr/puppet-module-skeleton/, since the skeleton loads the `semantic` gem from Puppet's vendor dir to validate a module's metadata.json. We’re planning to ship a Puppet 4.9.1 gem ASAP that will warn that this has been removed (but does not fail directly). https://tickets.puppetlabs.com/browse/PUP-7156 Additionally, if you have a "classic" hiera.yaml config file in an environment root (perhaps because your control repository has one checked in, and r10k deploys it into /etc/puppet/code/environments//hiera.yaml), you'll see the error "a hiera.yaml version 3 cannot be used in an environment". This will become a warning instead of a hard error, and until then you can move it into a subdirectory where it will be ignored. https://tickets.puppetlabs.com/browse/PUP-7165 New Platform Support • This release adds puppet-agent packages for Fedora 25. EOL Platforms As of this release, we are no longer providing puppet-agent packages for the following platforms: • Ubuntu 10.04 (Lucid) • Ubuntu 15.10 (Wily) • Mac OS X 10.9 • SLES 10 • Fedora 22 To install or upgrade Puppet Agent, follow the getting started directions: http://docs.puppetlabs.com/puppet/latest/reference/index.html For information on upcoming platform end-of-life (EOL) for Puppet Agent, please see our Platform Support Lifecycle page: https://puppet.com/content/platform-support-lifecycle Eric Sorenson - eric.soren...@puppet.com director of product, puppet ecosystem -- 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/7BBBDDE1-3606-45EA-8B6A-D95647EE18FF%40puppet.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Escape codes in collection types
This thing is nice that way: https://github.com/drwahl/puppet-git-hooks I recommend using the pre-receive hook on the server side. That way you can skip awkward conversations about how people should go the extra mile and exceed expectations by installing git hooks locally. Instead you get to have less awkward conversations about how people shouldn't push garbage to git repositories. On Wed, Feb 01, 2017 at 11:54:04PM +, Rob Nelson wrote: >It might be a good idea to add `puppet parser validate` and puppet-lint to >your pre commit hooks, they should help catch most similar issues. >On Wed, Feb 1, 2017 at 12:26 PM Joshua Schaeffer ><[1]jschaeffer0...@gmail.com> wrote: > >That should be $color = > > Wow, I knew it was something simple. I swear I looked at that for 10 > minutes straight and couldn't find the syntax error. Thanks for pointing > it out. I corrected the syntax error and it's all working correctly now. > Thanks, > Joshua > > -- > 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 [2]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [3]https://groups.google.com/d/msgid/puppet-users/dd919198-940a-41b7-8028-003227488d73%40googlegroups.com. > For more options, visit [4]https://groups.google.com/d/optout. > >-- >Rob Nelson > >-- >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 [5]puppet-users+unsubscr...@googlegroups.com. >To view this discussion on the web visit > > [6]https://groups.google.com/d/msgid/puppet-users/CAC76iT9x6A4gdfNO-3UAKz7xeq%3DPi7kJF3eDT38nU49fh2%3D7BQ%40mail.gmail.com. >For more options, visit [7]https://groups.google.com/d/optout. > > References > >Visible links >1. mailto:jschaeffer0...@gmail.com >2. mailto:puppet-users+unsubscr...@googlegroups.com >3. > https://groups.google.com/d/msgid/puppet-users/dd919198-940a-41b7-8028-003227488d73%40googlegroups.com?utm_medium=email&utm_source=footer >4. https://groups.google.com/d/optout >5. mailto:puppet-users+unsubscr...@googlegroups.com >6. > https://groups.google.com/d/msgid/puppet-users/CAC76iT9x6A4gdfNO-3UAKz7xeq%3DPi7kJF3eDT38nU49fh2%3D7BQ%40mail.gmail.com?utm_medium=email&utm_source=footer >7. 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/20170202202539.GA11574%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet upgrade broke puppet agent on my Oracle Linux 5 and 6 boxes
On ol7 boxes the puppet agent is working fine. This is what I have installed on one of my ol6 boxes: # rpm -qa |grep puppet mcollective-puppet-common-1.11.1-1.el6.noarch puppetlabs-release-22.0-2.noarch puppetlabs-release-pc1-1.1.0-5.el6.noarch mcollective-puppet-agent-1.11.1-1.el6.noarch puppet-agent-1.9.0-1.el6.x86_64 This is the error I'm getting: Error: Failed to apply catalog: Could not find dependent Service[mcollective] for File[/usr/libexec/mcollective/mcollective/agent/shell.ddl] at /etc/puppetlabs/code/environments/production/modules/mcollective/manifests/agents.pp:12 There is no agents.pp file on my systems. This is an empty directory: /etc/puppetlabs/code/environments/production/modules/ Anyone know how to recover from this? I'm in the process of trying to provision a ol6 box and can't. Thanks, Kenton Brede -- 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/CA%2BnSE38KDzg0zRsaFi%3Dgv2GC_4QjdhZqe4bDjNsiexfVLgWBiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet upgrade broke puppet agent on my Oracle Linux 5 and 6 boxes
As it turns out the agents.pp file is on my puppetmaster. If I comment out my 'mcollective' module then the next module in line, 'nagios' has issues: Error: Failed to apply catalog: Could not find dependent Service[nrpe] for File[/etc/nagios/nrpe.cfg] at /etc/puppetlabs/code/environments/production/modules/nagios/manifests/files.pp:7 Kenton Brede On Thu, Feb 2, 2017 at 3:02 PM, Kenton Brede wrote: > On ol7 boxes the puppet agent is working fine. > > This is what I have installed on one of my ol6 boxes: > > # rpm -qa |grep puppet > mcollective-puppet-common-1.11.1-1.el6.noarch > puppetlabs-release-22.0-2.noarch > puppetlabs-release-pc1-1.1.0-5.el6.noarch > mcollective-puppet-agent-1.11.1-1.el6.noarch > puppet-agent-1.9.0-1.el6.x86_64 > > This is the error I'm getting: > > Error: Failed to apply catalog: Could not find dependent > Service[mcollective] for > File[/usr/libexec/mcollective/mcollective/agent/shell.ddl] > at /etc/puppetlabs/code/environments/production/ > modules/mcollective/manifests/agents.pp:12 > > There is no agents.pp file on my systems. > > This is an empty directory: > > /etc/puppetlabs/code/environments/production/modules/ > > Anyone know how to recover from this? I'm in the process of trying to > provision a ol6 box and can't. > > Thanks, > > Kenton Brede > > > > > -- 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/CA%2BnSE39zK9hQxbHAzjo2EtMJJJZzGh7ZKhxhoyyGvvutX7tO%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet upgrade broke puppet agent on my Oracle Linux 5 and 6 boxes
Strange. It ended up being all my notify attributes quit working. A restart of puppetserver solved the issue. Kenton Brede On Thu, Feb 2, 2017 at 3:24 PM, Kenton Brede wrote: > As it turns out the agents.pp file is on my puppetmaster. If I comment > out my 'mcollective' module then the next module in line, 'nagios' has > issues: > > Error: Failed to apply catalog: Could not find dependent Service[nrpe] for > File[/etc/nagios/nrpe.cfg] at /etc/puppetlabs/code/ > environments/production/modules/nagios/manifests/files.pp:7 > > > > > > Kenton Brede > > > > > > On Thu, Feb 2, 2017 at 3:02 PM, Kenton Brede wrote: > >> On ol7 boxes the puppet agent is working fine. >> >> This is what I have installed on one of my ol6 boxes: >> >> # rpm -qa |grep puppet >> mcollective-puppet-common-1.11.1-1.el6.noarch >> puppetlabs-release-22.0-2.noarch >> puppetlabs-release-pc1-1.1.0-5.el6.noarch >> mcollective-puppet-agent-1.11.1-1.el6.noarch >> puppet-agent-1.9.0-1.el6.x86_64 >> >> This is the error I'm getting: >> >> Error: Failed to apply catalog: Could not find dependent >> Service[mcollective] for >> File[/usr/libexec/mcollective/mcollective/agent/shell.ddl] >> at /etc/puppetlabs/code/environments/production/modules/ >> mcollective/manifests/agents.pp:12 >> >> There is no agents.pp file on my systems. >> >> This is an empty directory: >> >> /etc/puppetlabs/code/environments/production/modules/ >> >> Anyone know how to recover from this? I'm in the process of trying to >> provision a ol6 box and can't. >> >> Thanks, >> >> Kenton Brede >> >> >> >> >> > -- 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/CA%2BnSE38_%3DM__0ri7yW1%2Bb6OQrzZaXmJJx0cFk%2B-DurOXj1MeZA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
