Re: [Puppet-dev] Port 8140/TCP (PuppetServer) close

[Rob Nelson]

You should probably start by verifying it is listening on port 8140, then
look at any firewalls between the agents and the master - including
iptables or other OS-level firewalls - to ensure they are allowing the
traffic.

On Sun, Mar 11, 2018 at 7:59 AM Aécio <aeciopi...@gmail.com> wrote:

> Hello guys!
>
> I have the following problem: every 30 or 40 minutes, I get a notification
> that port 8140 / TCP (from PuppetServer) is closed and puppet-agent (from
> client servers) can not get the catalog and / or send reports.
>
> Looking at the log in /var/log/puppetlabs/puppetserver/puppetserver.log
> and watching the process, I saw that the puppetserver service did not stop.
>
> Can anyone help me solve this problem?
>
> What have I done?
>
> 1) I have read the page
> https://puppet.com/docs/puppetserver/2.7/tuning_guide.html
>
> 2) I installed PuppetServer 2.8.1 (compatible with Puppet4.x) on a server
> with 6GB of RAM and 2 vCPU and changed the following settings:
>
> # /etc/default/puppetserver
> JAVA_ARGS = "- Xms2G -Xmx2G"
>
> # /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf
> max-active-instances: 4
>
> Unfortunately, the issue has not been resolved.
>
> Thanks for the attention and any help.
>
> Aécio Pires
> Book of Puppet => novatec.com.br/livros/puppet
> Book of Zabbix => novatec.com.br/livros/zabbix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CALCxXJhp5806ZZPS9T0KNBUfhcpbeAmEK3C1s3RR8OUOAT9oFw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CALCxXJhp5806ZZPS9T0KNBUfhcpbeAmEK3C1s3RR8OUOAT9oFw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Rob Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9mmPvWdPHJt6yR31pFiujuVwpvkX_NvgeR7-%3Ddv1-KNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Anyway to trigger cleanups when classes are removed from a host?

[Rob Nelson]

Ah, sudoers files. That narrows it down - less of a class issue and more of
a multiple defined type instance issue. What module are you using,
specifically? I use saz/sudo because it purges ALL sudoer.d files that it
does not manage. So if on one run, there were say ERPM01-30 users and then
on the next only ERPM01 and ERPM10-30 were present, ERPM02-09 would be
automatically purged.

If I understand the problem correctly, I think your solution is to look at
the module you're using to see if it has a method to purge non-managed
sudoer.d files, and if not, look at adding that to the module or switching
to a module like saz/sudo.

If I did not understand the problem, let me know. I think I have another
idea, but best to see if I'm on the right track rather than confusing the
issue :)


Rob Nelson
rnels...@gmail.com

On Wed, Oct 4, 2017 at 8:36 PM, James Perry <jjperr...@gmail.com> wrote:

> Thanks Rob.
>>
>>
> As for reclassifying nodes that is a use case outside of what I'm trying
> to accomplish.
>
> Mostly I was trying to work more a scenario like the following:
>
> I have a set of restricted accounts for use with ERPM.on Linux. Each DBA
> is assigned a Linux local ERPM user that is the same on all hosts due to
> how ERPM is configured. Each of the ERPM account has specific sudo rules
> assigned to it using the sudoers module from Puppet Forge. Basically each
> erpm01-erpm30 user has the necessary groups, permissions, home and sudo
> rules for that account. Each user is a defined class so we can add
> individual ones on the host where they are required. I can't set the ERPMXX
> class to absent as that will remove it globally, which we don't want. I
> knew ways to work around this, but I'm trying to keep things as clean and
> simple as possible so we don't have to touch the code except to add new
> functionality. Our level on admins are given access in Foreman to add the
> class so they need not touch any code.
>
> ---
>
> Based on your explanation, how can I query / access the state Puppet knows
> for a host with regard to classes it doesn't have assigned?
>
> I would like to write code to check for the absence of a class/classes and
> then tell puppet what I want it to mean when the class is absent. Using the
> example above, it would loop through all of the ERPMXX classes to detect
> those that aren't present. When one is found to not be present it would
> define the state noting for ensure => absent for that user. If the class is
> there it does nothing for that user.
>
> Do as you noted in your Example for Apache, packages to know to be
> installed solely for Apache dependencies could be defined and set ensure =>
> "absent" and any other steps required to handle the absence of the class.
>
> I know i don't even have a partial grasp of the intricacies of the Puppet
> internals, so being able to check the state of classes being present or
> absent on the host other than from the host's classes.txt file.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/1dd6e4f0-fff1-41a8-bad3-7d502a8bae7a%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/1dd6e4f0-fff1-41a8-bad3-7d502a8bae7a%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8gfSr-L78-YxAjisba9E9RC6c%3DzkF-0-eX9iJNrMQzbg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Anyway to trigger cleanups when classes are removed from a host?

[Rob Nelson]

Puppet enforces state. It does know about state you have not defined. So if
you have a class that takes an ensure propert of absent, for instance, it
can enforce that. But it cannot guess what “the absence of this class”
means as a state model. Remember, your class model may say ‘make sure
apache is installed’, but the actual state model will apply all the
dependencies for apache. Turning that around to ‘make sure apache is NOT
installed’ will not remove the dependencies that were installed. So no,
there is no generic ‘absent’ value you can use to remove a class.

It is worth pointing out that immutable or ephemeral image patterns can
help with this. In essence, you do not change the classification of an
existing node, you delete that node and create a new node with the proper
classification. No chance of any sort of cruft or manual configuration
modifications persisting. Of course, that’s a goal most cannot fully
approach, but it is something to aspire to. I don’t know what your classes
are, but most people would not want to reclassify a database node as a web
app node, or vice verse. They may be okay with reclassifying a web app node
from application A to application B. There’s some value in those models
even if you can’t implement them fully.

On Wed, Oct 4, 2017 at 11:57 AM James Perry <jjperr...@gmail.com> wrote:

> Recently we have been changing out some software that was deployed via
> tarball extractions. Now we have a different app that deploys via RPM. To
> not break the legacy hosts where the new software doesn't we created a
> whole new class for deployments and setups on the new software.
>
> I've Googled, dug through forum posts and looked into a lot f modules, but
> couldn't find anyway to make what i would like to see if it is possible to
> do.
>
> Is there a way do a cleanup on removing the class? Ideally it would be
> nice to have some way to cleanup as well as check to be sure it is cleaned
> up if it doesn't have the class.
>
> I tried to write a class to do something like this for a specific set of
> classes to see if host has them as part of their catalog. Somewhere deep in
> my memory I think I remember there being a way to access the classes using
> a built-in call, but can;t seem to find it. I know I can reference
> the /opt/puppetlabs/puppet/cache/state/classes.txt file, but i was trying
> to be sure that the data was accurate by pulling off the master.
>
>Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/ededc7b7-c4cd-4820-bd72-be9103753b72%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/ededc7b7-c4cd-4820-bd72-be9103753b72%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Rob Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9wnqmvfEaXVLN6j4jabPo_LMKMQ12quZCqsr_BdzMgkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Steps to build a Puppet 4 install in my home directory for building modules

[Rob Nelson]

If you're talking about testing it, it gets its own test like
https://github.com/puppetlabs/puppetlabs-java/blob/master/spec/unit/facter/java_version_spec.rb.
If you're talking about using the custom fact in an otherwise unrelated
unit test. it depends on who sets the fact, and where; you may need to mock
it up or just set it in a `let :facts` block for simplicity.


Rob Nelson
rnels...@gmail.com

On Mon, Jul 24, 2017 at 2:42 PM, James Perry <jjperr...@gmail.com> wrote:

> Thanks.
>>
>
> I had looked at these but was missing something along the way.  I now have
> what appears to be a working setup and a *rake rspec* is now properly
> mocking and testing the modules.
>
> Now I just have to figure out why it isn't picking up the custom fact.
> That will require more RTFM and Google.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/ad122dc6-7a12-4770-b115-dc0436fdc17c%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/ad122dc6-7a12-4770-b115-dc0436fdc17c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8DxrrneURYJMMJH9QHOuEKkGpB2aTVvMFXho6PHcdo3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Steps to build a Puppet 4 install in my home directory for building modules

[Rob Nelson]

James,

As you have discovered, the setup you want is not quite documented the way
or in the locations you would expect, but it is documented in many places,
such as https://puppet.com/blog/unit-testing-rspec-puppet-for-beginners and
https://puppet.com/blog/use-onceover-start-testing-rspec-puppet.

IMO, what you really want to do is integrate tests with your
version-controlled code, in-place, rather than replicating it somewhere
else. You can do this by using ruby's bundler and a Gemfile to get started,
then add a spec/spec_helper.rb and spec/classes/*_spec.rb files for unit
tests and so on and so forth. But, you don't actually need puppet
installed, as that can come from a gem in the bundler setup. There's a lot
to do and many ways to do it, so there's no single solution to choose.

I've written a lot about my explorations with rspec on my blog (
https://rnelson0.com/?s=rspec) but here's how I would start. Use
puppet-module-skeleton (https://github.com/garethr/puppet-module-skeleton)
which creates a new module with rspec tests. It is designed for a module
rather than a controlrepo, so will take a little re-working to align it
properly for that (
https://rnelson0.com/2015/11/24/modern-rspec-puppet-practices/ and
optionally
https://rnelson0.com/2016/11/06/puppet-tech-debt-moving-rspec-tests/), but
is pretty good for both. Once you get it all working, you commit the
changes to your module/controlrepo and then it's bundled with your puppet
code, and thus always available for testing. It does mean the tests are
deployed on your master, but aside from a little extra disk space, it will
have no impact on agents connecting and should not be a concern. It's also
portable for when you get a vagrant or docker setup going.

With the bundler/rspec framework in place, your workflow becomes:
* Clone your controlrepo
* Checkout a feature branch for changes
* Run `bundle install` with appropriate args (I use `bundle install --path
vendor --without system_tests development` most of the time)
* Run `bundle exec rake test` to run all the tests (the target `spec`, or
the pair `spec_prep` and `spec_clean` will JUST run your unit tests),
everything should pass
* Make all the edits you need
* Run `bundle exec rake test` and ensure the tests continue to pass. If
not, repeat the previous step until tests do pass.
* Commit your code, push to upstream

There are plenty of examples of control repos out there but not all have a
working test setup included. Check out these two that show the example:
* https://github.com/example42/psick
* https://github.com/puppetinabox/controlrepo

I hope this helps!


Rob Nelson
rnels...@gmail.com

On Tue, Jul 18, 2017 at 7:51 PM, James Perry <jjperr...@gmail.com> wrote:

> Years ago there were a lot of docs about how to setup Puppet to allow
> someone to build modules outside having to have a master/client setup using
> puppet apply.
>
> I am trying to figure out the very cryptic world of spec/rspec, as it
> seems to not be documented very well anywhere for anyone other than someone
> that already knows it, In doing so I don't want to be able to develop in my
> home directory in a server versus having to develop modules and test with
> rspec against a full puppet server configuration.
>
> So far I have found little bits and pieces around, but nothing definitive
> or documented well for building something of this nature. The best I found
> so far were pre-built Ubuntu Docker containers or Vagrant builds. I don't
> have access to either presently or the time to build out a server to handle
> hosting either.
>
> Does anyone have a guide to setting up a stand-alone puppet client for
> development.  There used to be a rspec-puppet.com/setup page and that is
> what is linked from inside the documentation, but the page is gone.
>
> What I have so far is:
>
> 1. .Install puppet-agent to the host as root.
> 2. Setup paths to use the Ruby configuration from the puppet-agent so that
> the any gem add-ons are compatible with the version of the puppet-agent
> RPM.
> 3. Install puppetlabs-stdlib, rspec-puppet and any dependencies they
> require.
>
> When I have done a puppet module generate  and a rspec-puppet-init,
> I create a basic test to ensure the module compiles, as noted on the
> rspec-puppet Github page https://github.com/rodjek/rspec-puppet, That
> fails saying it can find compile.
>
> describe 'mymodule' do
>it { is_expected.to compile }
> end
>
> Any other tests that "should" work don't. either.
>
> So in modules/test/manifests/init.pp I have:
> class test {
>package { 'somepackage':
> ensure => present,
>   }
> }
>
> And my modules/test/spec/class/init_spec.rb has
>
> require 'spec_helper'
>
> describe 'test' do
> it { is_expected.to contain('somepackage').with_ensure('present')
> end
>
> So sin

[Puppet-dev] Re: puppet-lint triage today at 2000-2100 UTC

[Rob Nelson]

Ah, timezones are hard! It will be at 2000-2100 UTC, which is 1600-1700 
Eastern. Sorry for the confusion.

On Thursday, June 15, 2017 at 8:03:56 AM UTC-4, Rob Nelson wrote:
>
> If you have issues/PRs or just interest in puppet-lint, the bi-monthly 
> triage is today at 1600-1700 UTC.
>
> BlueJeans: https://bluejeans.com/280736660
> Info/Previous minutes: 
> https://github.com/voxpupuli/community-triage/tree/master/puppet-lint
>
> Hope to see you there!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/fe593dad-0caa-4dba-a951-8755c04664ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] puppet-lint triage today at 1600-1700 UTC

[Rob Nelson]

If you have issues/PRs or just interest in puppet-lint, the bi-monthly 
triage is today at 1600-1700 UTC.

BlueJeans: https://bluejeans.com/280736660
Info/Previous minutes: 
https://github.com/voxpupuli/community-triage/tree/master/puppet-lint

Hope to see you there!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/b56f6637-bf3c-405f-9a3b-10f972cc733d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: puppet-lint triage 4/20

[Rob Nelson]

I apologize that there was no triage meeting yesterday, I had some 
unexpected issues to deal with (but everything's okay now!). The next 
meeting will be on 6/15/2017.

If there is interest in an ad-hoc triage meeting before then, please let me 
know and I will try and put something together.

On Thursday, April 13, 2017 at 8:47:16 AM UTC-4, Rob Nelson wrote:
>
> As a reminder, next Thursday, 4/20/2017, is the next bi-monthly 
> puppet-lint triage, starting at 4PM Eastern / 1PM Pacific and using the 
> puppet triage meeting room, https://bluejeans.com/280736660
>
> I'm sending this reminder well in advance since the call is pretty new, 
> but in the future, reminders will be limited to shortly before the call 
> starts. More info on the call's schedule and previous minutes can be found 
> at https://github.com/voxpupuli/community-triage/blob/master/puppet-lint/ 
> <https://github.com/voxpupuli/community-triage/blob/master/puppet-lint/notes/2016-12-21.md>
> .
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/64dd2fbc-132b-4036-bb9c-d480959ec1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] puppet-lint triage 4/20

[Rob Nelson]

 As a reminder, next Thursday, 4/20/2017, is the next bi-monthly 
puppet-lint triage, starting at 4PM Eastern / 1PM Pacific and using the 
puppet triage meeting room, https://bluejeans.com/280736660

I'm sending this reminder well in advance since the call is pretty new, but 
in the future, reminders will be limited to shortly before the call starts. 
More info on the call's schedule and previous minutes can be found at 
https://github.com/voxpupuli/community-triage/blob/master/puppet-lint/ 

.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/5297dc9a-8a8f-4291-9e38-b3aea7018b85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet 5 release planning

[Rob Nelson]

I second this. While PC1 didn't quite work out the way many expected, it
made it impossible to accidentally the whole (puppet 4) bottle when it came
to updating your machines still running puppet 3.


Rob Nelson
rnels...@gmail.com

On Fri, Mar 3, 2017 at 4:13 PM, Eli Young <elysc...@gmail.com> wrote:

> Rather than calling the new package repository "puppet", it might make
> more sense to call it "puppet5". That way, when Puppet 6 rolls around, it
> can go into its own repository ("puppet6") and people can change the
> repository over once they've tested that their code works with the new
> version.
>
> On Mon, Feb 27, 2017 at 3:59 PM, Eric Sorenson <eric.soren...@puppet.com>
> wrote:
>
>> Hi all - we're nearing the end of the Puppet 4.x series feature
>> development. It's been almost two years since Puppet 4.0 dropped and it
>> seems like an opportune time to start thinking about the next semver major.
>>
>> There was some discussion last year[0], but the development work is truly
>> rolling forward now, so I wanted to restart the conversation about Puppet 5
>> to elicit feedback and make sure to incorporate the community's needs into
>> the plan.
>>
>> The headline here is that the core open-source "Puppet Platform"
>> (puppet-agent, puppet-server, puppetdb) are moving to a more coordinated
>> release model, with compatibility guarantees and consistent versioning
>> among the components. The first release of this "Puppet Platform 5",
>> currently targeted at May, will bring these components' major versions
>> together and provide some nice features without a huge
>> backwards-incompatible break.
>>
>> A couple of FAQs, or rather questions I imagine will be frequently asked:
>>
>> Q: Puppet 5, what the hell eric0?! I just spent a month updating my code
>> to run under Puppet 4.
>> A: No Puppet code that works under Puppet 4 needs changing[1] to work
>> under 5. This is a semver major to release some backwards-incompatible
>> changes that have stacked up, plus some additional feature work, but does
>> not affect the language. Puppet 4 won't be EOL any time soon (and we're
>> guaranteeing commercial customer support until 2018) but we've got to keep
>> the platform moving forward. Plus, it seems like a good opportunity to
>> eliminate the confusion caused by "Puppet 4" being delivered in packages,
>> split between puppet-agent-1.x and puppet-server-2.x 
>>
>> Q: So what *is* in it? Why should I upgrade?
>> A: Lots of good stuff. Hiera 5 with eyaml is built-in; it's UTF-8 clean;
>> network comms are pure, sweet, fast JSON. Our current Ruby versions are
>> EOL'ed, so we're moving to MRI Ruby 2.4 on the agent and jruby9k on the
>> server. The PE-only puppet-server metrics service is getting some
>> enhancements and will be open-sourced.
>>
>> Q: How's it going to be delivered? Are Puppet Collections still a thing?
>> A: Funny you should ask. As we kicked around a couple of months ago[3],
>> it's been two years and the collections idea just hasn't worked out in
>> practice, so it seems wise to iterate and keep evolving. The current plan
>> is to create a new repo, parallel with the existing PC1 repos, simply named
>> 'puppet'. The platform components will roll into it and future
>> semver-majors will be coordinated across the components, hopefully leading
>> to smaller, easily digestible chunks of change.
>>
>> You can see the complete list of changes (which will evolve as we gather
>> feedback and adjust scope) at this JIRA query[2]. If there's anything on
>> the roster that looks like it'll break your world — or, conversely, if you
>> want to nominate a change that's important to you but isn't currently on
>> the list — this thread is the place to do that.
>>
>> --eric0
>>
>> [0] https://groups.google.com/d/msg/puppet-dev/RHa2tMPRTx4/sA8RX_gS1ogJ
>> [1] I'm reserving a tiny, tiny asterisk for some Ruby extensions that use
>> internal APIs that may change, like pre-Puppet 4.9 lookup extensions.
>> [2] https://tickets.puppetlabs.com/issues/?filter=12940
>> [3] https://groups.google.com/d/topic/puppet-dev/3-HSUz5OnHg/discussion
>>
>> Eric Sorenson - eric.soren...@puppet.com
>> director of product, ecosystem and platform
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on t

[Puppet-dev] Re: puppet-lint triage on 2/23/2017

[Rob Nelson]

I've added a calendar invite to the triage repo. Save 
https://raw.githubusercontent.com/voxpupuli/community-triage/master/puppet-lint/invite.ics
 
as a .ics file and you should be able to add it to your calendar. I've 
attached a copy as well, but any future updates will likely be in the git 
repo only.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/e29ff6a3-b298-4231-b9a6-9085258319b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=America/New_York:20170420T16
DTEND;TZID=America/New_York:20170420T17
RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=3TH
DTSTAMP:20170224T132940Z
ORGANIZER;CN=Rob Nelson:mailto:rnels...@gmail.com
UID:fmnd0sfdiqo12kq8b7shqqu...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Rob Nelson;X-NUM-GUESTS=0:mailto:rnels...@gmail.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=rn7...@att.com;X-NUM-GUESTS=0:mailto:rn7...@att.com
CREATED:20170224T132940Z
DESCRIPTION:https://bluejeans.com/280736660\n\nBi-monthly triage call. See https://github.com/voxpupuli/community-triage/tree/master/puppet-lint for more information and meeting minutes.
LAST-MODIFIED:20170224T132940Z
LOCATION:https://bluejeans.com/280736660
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:puppet-lint triage
TRANSP:OPAQUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:This is an event reminder
TRIGGER:-P0DT0H15M0S
END:VALARM
END:VEVENT
END:VCALENDAR

[Puppet-dev] Re: puppet-lint triage on 2/23/2017

[Rob Nelson]

Thanks to all who attended the triage call today! Minutes are at 
https://github.com/voxpupuli/community-triage/blob/master/puppet-lint/notes/2017-02-23.md.
 
The next puppet-lint triage meeting will be *April 20, 2017 @ 1PM Pacific*.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/e9b5518e-70ca-4b50-8cf1-50ffbeac5ae8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] puppet-lint triage on 2/23/2017

[Rob Nelson]

All,

I would like to invite you to attend the second of our bi-monthly 
puppet-lint triage calls. It will be on February 23, 2017 @ 2100 UTC (4PM 
Eastern / 1PM Pacific) and use the puppet triage meeting room, 
https://bluejeans.com/280736660

You can see the first meeting's notes at 
https://github.com/voxpupuli/community-triage/blob/master/puppet-lint/notes/2016-12-21.md
 
and we add future meeting minutes in that repo. If you cannot attend but 
have something to discuss, feel free to respond here, reply directly to me, 
or add a note to your PR/issue with your concerns.

As we are just starting these calls, we're trying to work out the best 
schedule for regular attendance. Any and all suggestions are welcome at 
https://github.com/rodjek/puppet-lint/issues/623. 

Thanks!

Rob Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/d605dcf0-c24a-4ac2-a051-cd94ee144a3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Puppet Module Gem Dependency?

[Rob Nelson]

Zabbix uses the zabbixapi gem, you can take a look at how it implements it
to be sure it's present before the type and provider is used. There's no
simple tutorial about how that's laid out but you can see the references at
https://github.com/voxpupuli/puppet-zabbix/search?utf8=%E2%9C%93=zabbixapi

On Sat, Dec 24, 2016 at 4:41 PM <bryan.st...@gmail.com> wrote:

> Hello All,
>
> I'm updating a module that will require a ruby gem (e.g. xml-simple) for
> one of the custom providers. How does Puppet make sure that the gem is
> available and installed when the module is installed? Does a *puppet
> module install* also install any dependent gems? How does it know which
> gems are needed to install? To where does Puppet install gems?
>
> Or is there something else that consumers of my module will need to do to
> ensure that the gems are available before they try to use the module's
> resources?
>
> I tried searching both this group and Puppet Users but didn't find much.
> May be the key-words aren't right.
>
> Anyway, any assistance would be appreciated.
>
> -Stopp
>
>
>
>
>
>
>
>
> --
>
>
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
>
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/67b2a7a4-4551-4ec8-9f3e-5e5d3383b425%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/67b2a7a4-4551-4ec8-9f3e-5e5d3383b425%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
Rob Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT-T1DBPjMLsN2-Os8ZFvA%3D0VfDf9xm0_M2tKAb1%2B_2ZvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Rethinking Collections

[Rob Nelson]

Eric, what IS the rough outline on how to avoid incompatible updates with a
consolidated repo? I'm particularly interested in how it would work with
puppetlabs/puppet_agent (since `latest` would suddenly have a much
different meaning).


Rob Nelson
rnels...@gmail.com

On Mon, Dec 5, 2016 at 4:25 PM, Eric Sorenson <eric.soren...@puppet.com>
wrote:

> Hi all. tl;dr: We are proposing moving the open source package
> repositories back to a single repository for Puppet-owned projects and
> their dependencies. This represents a shift from our stated plan to release
> major-version releases that might contain backwards incompatibilities into
> their own Puppet Collection repositories, but as a result it will be less
> confusing to use the packages and easier to stay current.
>
> Long version: When we released Puppet 3.0 in 2013, backward
> incompatibilities between it and Puppet 2.7 broke a number of sites who had
> configured their provisioning or package updates to install the latest
> version of Puppet from our repositories. In order to prevent similar
> breakage when we released Puppet 4 in April 2015, we introduced it into a
> new repository called Puppet Collection 1 (PC1), so users had to opt in
> rather than opt out. The idea was that future backward-incompatible updates
> would trigger new Puppet Collections, which would also be opt-in, so that a
> user could stay on PC1 and only move to PC2 when they were ready
> (background reading: https://puppet.com/blog/welcome-to-puppet-collections
> ).  In practice, the switching costs to get everyone onto a new repository
> seemed really high and for the most part the impact of releasing into the
> existing collection was low, so instead we either shipped releases like
> PuppetDB 4.0 into PC1 or deferred shipping versions with big changes, such
> when we rolled back from Ruby 2.3 to 2.1 for puppet-agent-1.7.0.
>
> We've been exploring our options to balance between the following criteria:
>
> - avoid breaking sites, to not repeat the Puppet 2 to 3 pain
> - provide a set of component packages that are known to work with each
> other, and provide a basis for Puppet Enterprise platform releases
> - encourage rapid adoption of new releases by the open source community
> - provide commercial differentiation on support lifecycle, similar to the
> RHEL / Fedora model
>
> We talked through a number of options in pretty exhaustive detail and have
> tentatively settled on this as the best – or maybe "least bad" – course of
> action:
>
> - make a release package with a new name (probably "puppet-release"),
> eliminating the public face of "Collections"
> - move the existing repository directory structure over to a top-level
> "puppet" repo, leaving links in place for current PC1 users to avoid
> breaking them.
> - publish and promote the plan (probably including re-visiting that blog
> post above and making a new one to advertise what's happening), including
> instructions on how to avoid incompatible updates if you don't want them,
> and updating https://docs.puppet.com/puppet/latest/reference/
> puppet_collections.html#puppet-collection-contents
> - continue publishing any and all open-source releases to the "puppet"
> repo, including major-version releases.
>
> The patching/update policy will remain as it is today, where only the
> latest series receives patches. For instance, once Puppet 4.9.0 is out,
> there will be no more 4.8.x releases. The package repositories which
> contain Long Term Support Puppet Enterprise point releases will continue to
> be private, but the branches/tags of the components that comprise these
> point releases will remain public, so people could rebuild them if they
> wanted to.
>
> Speaking of community upstream, we want to enable builds of Puppet that
> behave reliably, stay current with our bugfixes and release cadence, and
> run on OSes that Puppet Inc. doesn't commercially support. We've been
> working to enable outside folks to rebuild and distribute our software and
> are going to continue to focus energy on this. As a few examples, we are:
> - working to get Puppet 4.x and Facter 3 built as standalone packages for
> Solaris
> - investigating the OS-native build toolchain for OSes with current
> compilers like Ubuntu Yakkety and Fedora 25 (to avoid having to rebuild the
> world to get the C++ packages built)
> - making facter-3 installable via gem for testing and distro packaging
> (FACT-1523)
> - working on including the Docker-ized Puppet Server stack into CI so new
> versions are automatically built and uploaded to docker hub along with
> traditional packages.
>
> I'd love to hear your feedback (just reply on this thread) on the proposal
> overall an

Re: [Puppet-dev] Re: stdlib validate_* and is_* function deprecation

[Rob Nelson]

On Monday, October 24, 2016 at 12:53:50 PM UTC-4, Alex Schultz wrote:
>
> Yea it's not removed but it's about consideration for the end user and 
> how they will now be flooded with warnings unless they do a bunch of 
> configurations to silence them (bad UX and probably a bad idea) or 
> find all the instances of the deprecated functions and update them if 
> they can (also bad UX).   It would have been beneficial to add when it 
> will be removed in such messaging to set expectations. 
>

I think this deprecation within 4.x is correct. Semver says that a function 
has to be marked as deprecated for at least one published version before it 
is removed in a new MAJOR version. Thus, it is marked as deprecated within 
4.x of the module and will be removed at a future major release, presumably 
5.0.0 (but maybe 6? difficult to plan these things ahead). The deprecation 
itself does not warrant a MAJOR bump, but the backwards-incompatible 
removal does. See 
http://semver.org/#how-should-i-handle-deprecating-functionality, and 
http://semver.org/#spec-item-7 and http://semver.org/#spec-item-8 
specifically.
 

> As an aside we recently got nailed when puppetlabs-ntp became no 
> longer puppet3 compatible on master prior to the new version being 
> released.  As operators and developers, these incompatible transitions 
> really need to be well thought out on their impact.  I can't count the 
> number of times we've been hit when someone decided to change their 
> gem (or ruby) dependencies mid release cycle and it breaks everything 
> even if we don't actually consume any code from that module. Sorry 
> it's a major pet peeve of mine when we have to drop everything and go 
> figure out who's doing breaking changes mid cycle and either pin or 
> find a work around because of backwards incompatibilities. 
>

Ugh, you've got my sympathies about how ruby and its gems generally handle 
dependencies. I've gone round and round with gem authors about this before 
and it almost always falls on deaf ears (ex: 
https://github.com/guard/listen/issues/374). Puppet is not immune to making 
mistakes or challenging decisions with this loosely defined standard, but 
my experience has been that they hew closer to both the letter and spirit 
of semver, as described above, and far more frequently than other vendors. 
As Erik suggests, version pinning is suggested to avoid upgrades affecting 
you inadvertently. When you make a conscious decision to upgrade, then at 
least you are assured the behavior is in a window where you can discern if 
you want to commit to it or roll back until a later date.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/705f0cd6-66f7-4de5-bfeb-f68b9b55c5e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] stdlib validate_* and is_* function deprecation

[Rob Nelson]

 may need newer version of stdlib.
>
> This just seems like something that would be better suited for the next
> major version than trying to do it mid stdlib 4.x and let people opt in to
> it as puppet 3 support fully dies off.
>
> Thanks,
> -Alex
>
> p.s.  I'm not sure that "if $var =~ Stdlib::Compat::Array" is nearly as
> convenient (or readable) as if is_array($var) and trying to use standard
> types instead of just validate_re is just painful.
>
>
>
>> Having to go through our modules and switch out to the validate_legacy
>>> functions is an effort we don't have the resources to undertake and the
>>> deprecation notices aren't something we can live with as they make it very
>>> hard to figure out when something actually breaks.
>>>
>>
>> Please see the documentation for the deprecation function in the stdlib
>> readme on how to turn on/off deprecations in different situations (via
>> puppet configuration on your master, or a environment variable during
>> testing). You always have the possibility to stay on stdlib 4.12 until you
>> are ready to start your upgrade project.
>>
>>
>>> Additionally I'd like to point out that the deprecation notices make it
>>> next to impossible to figure out what is deprecated, see
>>> http://logs.openstack.org/89/388589/1/gate/gate-puppet-opens
>>> tack-integration-4-scenario001-tempest-centos-7/fc2567b/
>>> console.html#_2016-10-19_22_24_59_667975
>>>
>>>
>> Crap. I missed that one. I'm currently at puppetconf, and travelling home
>> afterwards, so I won't be able to look into it immediately, but I've
>> created https://tickets.puppetlabs.com/browse/MODULES-3993 to track
>> this, and will get to it next week. Until then, grepping for
>> 'validate_|is_' is probably a good first approximation of everything you'll
>> need to address.
>>
>>
>> Cheers, David
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/7d10843f-4647-4e07-acea-95bd765431b4%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/7d10843f-4647-4e07-acea-95bd765431b4%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9Spz5we7kRiWNCJW%3Dw1W%2BdFKv6PSQO9j%3DvWefGVSU3Vw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Host file replaced

[Rob Nelson]

You're specifically looking for a resource called `resources` with the
title `host`, as shown at
http://www.puppetcookbook.com/posts/remove-all-unmanaged-host-entries.html.
More info at
https://docs.puppet.com/puppet/latest/reference/type.html#resources


Rob Nelson
rnels...@gmail.com

On Wed, Oct 5, 2016 at 7:56 AM, Aditya Gupta <adityalnc...@gmail.com> wrote:

> Thanks for the answer.
>
> I am using standard puppet resource type:
>
> https://docs.puppet.com/puppet/latest/reference/types/host.html
>
> and i can not see support of purge parameter in it.
>
>
> On Wednesday, October 5, 2016 at 12:44:38 PM UTC+5:30, Craig Dunn wrote:
>>
>>
>>
>> On Wed, Oct 5, 2016 at 12:24 AM, Aditya Gupta <aditya...@gmail.com>
>> wrote:
>>
>>> Hello All,
>>> I am using host resources in my puppet class to manage hosts file of the
>>> client.
>>>
>>> I am facing one issue where if I have already connected client to the
>>> puppet server where hosts file have its own entries as well as entries
>>> defined by puppet server .
>>>
>>> But whenever I replaced my hosts file from some other server then in
>>> next puppet run my old entries removed from the hosts file and I can only
>>> see entries managed by puppet.
>>>
>>>
>>>
>> FYI in future this type of question is probably more suited to
>> puppet-users than puppet-dev.
>>
>> It sounds like resource purging, meaning that Puppet will purge any
>> resources found that are not under Puppet control.  You don't mention if
>> you use a Forge module to manage hosts, or something home grown - if you're
>> using something like https://forge.puppet.com/ghoneycutt/hosts then
>> you'll need to set (or unset) the "purge_hosts" option.  Otherwise, you
>> might have something like this declared
>>
>> resources { 'hosts': purge => true }
>>
>> Either way, it should be easy enough to change the behaviour but without
>> knowing what module you are using I can't really tell you exactly how.
>>
>> Craig
>>
>> --
>> Enviatics |  Automation and Configuration Management
>> Puppet Labs Service Delivery Partner & Certified Consultant
>> http://www.enviatics.com | @Enviatics | cr...@enviatics.com
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/0b57afa6-4d5f-4a62-97fc-6c7f6b5a4bf2%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/0b57afa6-4d5f-4a62-97fc-6c7f6b5a4bf2%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT_7Vct5F_GA73Bqe4zhdM5b%3DvutkgUq3Aji8ZgC%3DHfTmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Detailed exit codes in facter

[Rob Nelson]

Will, I don't have any specific needs myself but there are probably two
other detailed exit codes I can envision. 1) there was a problem
calculating the value of the requested fact. 2) there was a problem
calculating the value of one or more facts, but at least one fact's value
was successfully calculated (most likely when used without a fact name in
the argument list). The latter I observed on switch gear where individual
facts that were not properly confined would fail to calculate because some
unix-ism was not present in the unix-ish OS.


Rob Nelson
rnels...@gmail.com

On Fri, Jul 8, 2016 at 5:38 PM, Will Hopper <whop...@puppet.com> wrote:

> Hey all,
>
> As brought up by https://tickets.puppetlabs.com/browse/FACT-1429, facter
> currently returns an exit code of 0 when a non-existent fact is queried.
> Thus, it's not possible to distinguish between a successful query and a
> silent failure other than by actually reading the output.
>
> To improve on this, facter should produce meaningful exit codes. For
> backwards compatibility, we're thinking about adding a
> `--detailed-exitcodes` option. Our questions for the community are: are
> there other scenarios you'd like to see exit codes better utilized for?
> And, are there specific codes would you like to see for these scenarios,
> including our example non-existent fact query?
>
> Thanks!
>
> --
> William Hopper
> Puppet Platform Engineer
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/cd25a8bd-a686-4432-9756-d4f4208cd7a1%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/cd25a8bd-a686-4432-9756-d4f4208cd7a1%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT_JXjJzoY2oqp9JUZ0Ufyu2Gy%2Bje6ZOAmqfbPxh-riLwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Community PR Trello board lives again!

[Rob Nelson]

Will, that's awesome, thanks for bringing that back!

As a point of curiosity, can you say what you're doing to sync things up? I
played with Zapier and some similar items myself and found them all kind of
lacking, with the exception of waffle.io even though it doesn't use Trello
itself. Thanks,


Rob Nelson
rnels...@gmail.com

On Tue, Jun 14, 2016 at 6:53 PM, Will Hopper <whop...@puppet.com> wrote:

> Hello, all!
>
> Once upon a time (in 2013), there was a Puppet Labs managed Trello board
> tracking community pull requests across the major core open source
> projects. This was great, as it added transparency to the state of the pull
> requests y'all had worked hard on and reduced the effort of bookkeeping on
> our part!
>
> As of today, this board is back, and (hopefully) better than ever! We on
> the core team will be using it to triage and review community contributions
> from now on, especially during our bi-weekly community pull request review
> sessions. Currently covered projects are puppet, facter, hiera, and
> puppet-strings.
>
> If you are interested in seeing the board in all of it's glory, you can
> find it here! https://trello.com/b/YCzBvzHW
>
> Additional details and descriptions of our process (and what those columns
> mean) can be found here:
> https://github.com/whopper/puppet-core-community-triage/blob/master/README.md
>
> If you are a contributor, know that your pull requests will be
> automatically added as cards on the board, and you can track their progress
> at any time. Other actions such as commenting, pushing commits, and
> rebasing will also automatically update the card location to hopefully make
> it easier for us to keep track of what's going on.
>
> Let us know if you encounter any weirdness!
>
> --
> William Hopper
> Puppet Platform Engineer
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/60a1000b-bab7-4b57-8c42-69bf413f10dd%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/60a1000b-bab7-4b57-8c42-69bf413f10dd%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8_gvDOQmF6jmsCF4gTzn7TFO_vWP0qNFu5me1oXS1H8w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Passing Credentials in Powershell Scripts

[Rob Nelson]

Can you pass a $PSCredential down, maybe as a File resource that the script
can rely on? The scripts may need modified per
https://technet.microsoft.com/en-us/magazine/ff714574.aspx


Rob Nelson
rnels...@gmail.com

On Wed, Apr 20, 2016 at 10:52 AM, Ian Oberst <ian.obe...@gmail.com> wrote:

> I've had a number of conversations with various Puppet folks about this
> and it remains a bit of a sticky issue, namely *how do we safely handle
> powershell scripts where we need to pass credentials or other sensitive
> information to Powershell?*
>
> The scenario here is that we have a situation where we need to give
> Powershell some credentials to perform some sort of work on the system. Due
> to restrictions we have to pass these credentials via Puppet in some
> fashion, e.g. we can't or don't have access to a key manager that
> Powershell can talk to directly, meaning that Puppet is the only route of
> providing the secrets to the node.  (I do understand there are other
> issues here as well, such as getting secrets securely passed in the
> catalog, but I'm setting that aside for now.)
>
>
> Recent incarnations of the Powershell provider all write a temp file to
> disk that contains the powershell code to be invoked. This means that if I
> have the credentials placed directly in the script (which generally seems
> the route I have to take) that I'll have written them to disk.
> Additionally, the exec module itself has logging that will log the command
> out to both the event log and the Puppet report, which will expose
> credentials. None of these outcomes are very good.
>
>
> The approach I've tried to take is going the route of signed powershell
> scripts so we can invoke them with command line parameters rather than
> using stdin, which is the route the current Powershell provider takes. This
> seems at the moment to side-step some of the above mentioned problems
> depending on how you communicate those command line parameters to the
> provider. However, I'd like to align with the longer-term strategy, if
> possible, of how Powershell scripts are invoked within the Puppet supported
> provider.
>
>
> So...what's the best way of handling this?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/5bd0c1ad-d53a-4135-872c-62cfe4463cf5%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/5bd0c1ad-d53a-4135-872c-62cfe4463cf5%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8uj_pPuBzJzeX0%3Ds2yBJDAC-dtZS4VS0SMUgqaeBDwAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Euro/London Presence (was: Re: Re: The Future of Puppet [Was: Deprecation logs])

[Rob Nelson]

A workshop on building tests (or even two - one for module code, one for
types/providers/functions/etc) would also be valuable.


Rob Nelson
rnels...@gmail.com

On Wed, Apr 13, 2016 at 1:43 PM, Thomas Gelf <tho...@gelf.net> wrote:

> Am 13.04.2016 um 19:04 schrieb Thomas Gelf:
> > [...] but I have always been (and still am) asked whether there is
> > available something like a "Best practices training".
>
> NB: It didn't matter what kind of Puppet class this was. Something like
> a "Best practices training" was requested by all kind of attendees, from
> Fundamentals, Practitioner and Architect up to "Extending Puppet using
> Ruby". Feedback I of course forwarded to different Puppet(labs) training
> people at various occasions.
>
> Last time was at last years PuppetConf, had a very nice discussion, do
> not remember with whom. There I have been told that this could be part
> of the upcoming virtual classroom trainings. I realized right a couple
> of minutes ago that there is being offered "Appropriate Module Design"
> right now. That's great to see! From the description I cannot tell how
> deep it goes, but yes, that (and more like this) is what people request
> and need. Cool!
>
> I guess I mentioned this before, I stopped doing trainings when
> "Extending" was discontinued. Also something that could IMO be worth to
> re-evaluate. Even if we were not able to sell it many times, it was
> always appreciated. It was a challenging training, for the attendees and
> for the trainer. Especially when you allowed them to use their own
> notebooks and VMs. Newer rspec or puppet versions, different Ruby
> versions, stumbled over hidden monkey patching issues and much more :D
>
> But still, it always was a lot of fun. However, it would be challenging
> to this in a virtual classroom I guess.
>
> Cheers,
> Thomas
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/nem0g2%24nrh%241%40ger.gmane.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9can5EctHGuKLdkd_GfPqOh99r-5E%3Ds6%2B80OQnV2-Xxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Euro/London Presence (was: Re: Re: The Future of Puppet [Was: Deprecation logs])

[Rob Nelson]

More of a workshop, than a hackathon?


Rob Nelson
rnels...@gmail.com

On Wed, Apr 13, 2016 at 10:50 AM, Thomas Gelf <tho...@gelf.net> wrote:

> Am 13.04.2016 um 16:15 schrieb Nigel Kersten:
> > Thomas, it does feel like you're describing a mix between our
> > Contributor Summit and #puppethack events.
>
> Not really, I guess I didn't cleanly distinct my thoughts. It should
> read: "Hackathons will not work at entry-level-camps, but you could run
> something like a show-me-how-to-write-my-modules kickstart class". An
> extra day that could be booked (and payed) separately.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/nelmap%249h3%241%40ger.gmane.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT83MPOJiMOYccCu6WAe-mFw9y192pRo6Sar1sosA%2BPeeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Idea: Deprecation logs

[Rob Nelson]

I created https://tickets.puppetlabs.com/browse/PUP-6169 for those who want
to watch/vote/comment further. Thanks everyone!


Rob Nelson
rnels...@gmail.com

On Sun, Apr 10, 2016 at 9:16 PM, Rob Nelson <rnels...@gmail.com> wrote:

> On Sun, Apr 10, 2016 at 5:05 AM, Alex Harvey <alexharv...@gmail.com> wrote
>
>>
>> On 10 April 2016 at 03:59, R.I.Pienaar <r...@devco.net> wrote:
>>>
>>>
>>> Not really sure I follow most of this rant.
>>>
>>
>> Yes, fair enough.  It was a bit of an uncalled-for rant.
>>
>
> I think it's a legitimate concern. That's why I brought this up. Being
> surprised by some missing or changed functionality on an upgrade makes
> everyone less likely to upgrade. That's what I want to address. With that
> in mind, my proposal remains to provide deprecated features an ID, log them
> to a separate log, and/or provide tools and methods to present these
> deprecation messages to the user front and center on demand.
>
>
> Some greater context around this may help describe my concern and goals,
> as it really goes beyond just Puppet. Like many people, I and my employer
> use products from dozens of vendors and upgrades are, generally speaking,
> not fun. To pick on another vendor, going from ASA v8.2 to v8.3 or higher
> was fraught with a lot of danger. And that was just a minor release!
>
> Keeping track of where each vendor logs these messages - if they log them
> anywhere at all, rather than just place them in the release notes - is
> tiresome. I'd love to get ALL my vendors to create a central deprecation
> log so I could review it before upgrades and compare it against the release
> notes to see what will break. This would, in my opinion, be a competitive
> advantage for any vendor that did this. I'd be far more likely to use them
> over a competitor who ambushes me on every upgrade.
>
> We spoke of openness earlier, and Puppet is the only vendor I work with
> that is open enough that we might be able to get such a feature. With a
> little refinement past the initial implemention, I could then hold this up
> as an example of how to do things for my other vendors.
>
>
> So, if we can drag this discussion back around (split off from the other
> thread), are there any other suggestions I should include in the RFE ticket?
>
> Rob Nelson
> rnels...@gmail.com
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9QS9G5rTKLcXSemmQo3mmQFh8NnX%2B6Qr0K4f0Yoiz5hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Euro/London Presence (was: Re: [Puppet-dev] Re: The Future of Puppet [Was: Deprecation logs])

[Rob Nelson]

> I'd also be remiss not to point out we've got way more scope to have
> advanced talks at PuppetConf in the US and the CFP is open.
> http://2016.puppetconf.com/cfp-registration/
>

Speaking to the advanced realm, is there any possibility of slots longer
than 45 minutes? Even an extra 10 minutes could make a huge difference. Or
maybe some workshops, even if small in size?


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9O953kuqPAyF1nxWXWqWCuB32eeRsbq_VCeQGd3jp89w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: The Future of Puppet [Was: Deprecation logs]

[Rob Nelson]

>
> I think it's a great big programming anti-pattern, it's ugly as all hell,
> certainly nothing Apple would be seen dead near, and yet it's taking over.
> How?
>

Everyone wants one tool to do everything. If you need Ansible because your
non-Nexus Cisco gear has no chef/puppet agent, why not just make the switch
everywhere? Yeah, you and I think that's a dumb reason, but people do
things for (or in spite of) dumb reasons all the time. Short of spending
all their time getting agents for every networking device out there, I
don't think there's much you can do to stop these kinds of migrations. And
do you really want to appeal to people who enjoy ssh for loops? The best
you can hope for is some synergy, which seems to happen when people
actually understand what their different tools are good for - Puppet for CM
and Ansible to Orchestrate it.


> Look, reach out to them.  Somehow, I wish Puppet somehow could be more
> involved in the open source sites.  I'm sure you know where they all are.
> Be available to them.
>

I see PL employees on Reddit and SO and other sites all the time, and IRC
to boot. But those are sites I'm biased towards. What other sites do you
think are important and underserved?

Rob Nelson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9m79fVxWYZE6q9ypnV1XmZWw1_6vMCMT_m_-DFftwfyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: Idea: Deprecation logs

[Rob Nelson]

On Sun, Apr 10, 2016 at 5:05 AM, Alex Harvey <alexharv...@gmail.com> wrote

>
> On 10 April 2016 at 03:59, R.I.Pienaar <r...@devco.net> wrote:
>>
>>
>> Not really sure I follow most of this rant.
>>
>
> Yes, fair enough.  It was a bit of an uncalled-for rant.
>

I think it's a legitimate concern. That's why I brought this up. Being
surprised by some missing or changed functionality on an upgrade makes
everyone less likely to upgrade. That's what I want to address. With that
in mind, my proposal remains to provide deprecated features an ID, log them
to a separate log, and/or provide tools and methods to present these
deprecation messages to the user front and center on demand.


Some greater context around this may help describe my concern and goals, as
it really goes beyond just Puppet. Like many people, I and my employer use
products from dozens of vendors and upgrades are, generally speaking, not
fun. To pick on another vendor, going from ASA v8.2 to v8.3 or higher was
fraught with a lot of danger. And that was just a minor release!

Keeping track of where each vendor logs these messages - if they log them
anywhere at all, rather than just place them in the release notes - is
tiresome. I'd love to get ALL my vendors to create a central deprecation
log so I could review it before upgrades and compare it against the release
notes to see what will break. This would, in my opinion, be a competitive
advantage for any vendor that did this. I'd be far more likely to use them
over a competitor who ambushes me on every upgrade.

We spoke of openness earlier, and Puppet is the only vendor I work with
that is open enough that we might be able to get such a feature. With a
little refinement past the initial implemention, I could then hold this up
as an example of how to do things for my other vendors.


So, if we can drag this discussion back around (split off from the other
thread), are there any other suggestions I should include in the RFE ticket?

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9Dt1OCd8a3oTx-dd3s%3Dbt8sDFrSf6_SRODjC7HiJLzjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: The Future of Puppet [Was: Deprecation logs]

[Rob Nelson]

Lots of great discussion this weekend! I've changed the subject, since
we've changed our subject and this may help with future searches on the ML
archives.

No doubt. I had above conversation with a customer who I convinced to by
> PE the very same day. I explained it's advantages, they decided to buy
> it. But not before being assured that there is no hidden lock in. They
>

Of course there's lock in. You can't click a button and go from Puppet OSS
to Chef OSS; it's no different with enterprise versions. I'm sorry, but I
find this to be a really awkward concern to face. Even when you talk about
something known for lock-in, like Oracle or AWS, it's about getting the
data out. Some very well publicized stories about companies migrating away
from both and it's never easy. Lock in is perhaps the most specious concern
people have with software.


> themselves. But they wanted to make sure that Puppet was serious about
> being "open". By that time they have already been long time Puppet
>

Is their concern about being able to contribute to it or even fork? I
suspect that's what most lock in concerns are really based on.


> Btw, once there was "Live Management" a thing I tried to use that
> feature as a USP to sell PE. Honestly, I never had a serious use case
> for it. Some manager liked it, didn't work for tech people. Seen from
> today, I'm happy that it didn't work, as I would have felt very bad
> being forced to tell them that that promoted feature was going to be
> deprecated.
>

Agreed. This looked great on the surface. However, every action was owned
by the live management user which essentially made it unusable in any
regulated environment. I hope they find a way to fix that and bring it
back, but until then, it's absolutely best that it is not present at all.


> without buying PE. Someone who comes from a Ruby-based Puppet world
> already feels locked out by the Server being Java/Clojure, Facter a
> binary and everything AIO-packaged. That's what they only know from
> non-OSS vendors. Non of this is a problem on it's own, but together...
> one might get mixed feelings.
>

This is curious to me. Most I hear are happy to not have to worry about
passenger/apache/nginx changes and just let the vendor worry about that.
And ruby versions? That's a circle of hell on its own that no-one wants to
dive into (someone earlier mentioned getting things to work with ruby
1.8.7, but on those distros its possible to lack support for SNI and TLS
1.2, which are significant problems in 2016). I live mostly on the Ops
side, however, so may color my experiences far differently than others.


> versions. But because I see that there is quite some uncertainty amongst
> Puppet users regarding the direction OSS Puppet might take. And in my
> believes this is absolutely related to what Alex brought up. Unrequited
> love, feeling betrayed, not sure how to name it.
>

Uncertainty is bad. But I do sympathize with Eric - how to alleviate that
concern among users who don't engage with Puppet in the dozen different
ways available to them already?

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT88_-deGf5eNLRZqHdvAQtuHOQwzKC_%3D52LX5ctUz01-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: Idea: Deprecation logs

[Rob Nelson]

Yes, it should probably break less. But change is eternal, so it's going to
happen and its best we deal with it. It's not like this problem is
relegated to only CM tools! If something like this happens with Puppet, it
may end up being a good model to point other vendors to.

On Sunday, March 20, 2016, Thomas Gelf <tho...@gelf.net> wrote:

> Hi  Rob,
>
> nice proposal, would definitively help people to deal with the stated
> problem. Another approach could be to break and deprecate less things.
>
> Sure, I'm just kidding ;-) I love moving things forward. But you know,
> there's a grain of truth in every joke. We should not forget about the
> fact that by the end of the day we are talking about a tool designed to
> manage configuration.
>
> For many people right now the configuration manager is the fastest
> moving target in their tool stack. Your proposal is telling me that we
> have a cfgmgmt tool struggling with the amount of deprecations it
> produces. Sad story. We work for the tool, not the other way round.
>
> Cheers,
> Thomas
>
> Am 18.03.2016 um 19:12 schrieb Rob Nelson:
> > Happy Friday, everyone! This morning I had some semi-intelligible
> > thoughts about feature deprecation in Puppet, specifically because I got
> > bit with an upgrade issue last night. We do user stories a lot at work,
> > so I'm going to frame it that way. I was curious what other opinions
> > people have on this problem and how it can best be addressed. Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com <javascript:;>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/ncn1cd%24987%241%40ger.gmane.org
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT-k6cg8WEyR0qaeaf2a_qR2ghmhoeRvXE8u%3D53ueAJXeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Idea: Deprecation logs

[Rob Nelson]

Happy Friday, everyone! This morning I had some semi-intelligible thoughts
about feature deprecation in Puppet, specifically because I got bit with an
upgrade issue last night. We do user stories a lot at work, so I'm going to
frame it that way. I was curious what other opinions people have on this
problem and how it can best be addressed. Thanks!

*Problem*

When a user updates puppet components (server, agent, puppetdb, etc.), a
number of new features and options are typically made available, in
addition to the default location of some files being changed. Older
features, options, and file locations (collectively 'features' for
simplicity) are considered deprecated, to be removed in some future
version. Alerting the user of this is challenging for a few reasons.

1. Deprecation messages in puppet runs are noisy and most users disable
them as quickly as possible, never to be seen again.
2. Moving the messages to the component's log results in a bunch of needles
being added to the needlestack.
3. At the time of deprecation, it is usually impossible to determine what
future version will have no longer support the deprecated feature, so users
cannot plan for a timely removal of the feature.
4. When upgrades occur, deprecated or changed features often result in
failure to start/run, failure to properly apply entire catalogs due to the
loss of some components of it, poor or confusing logging about what caused
the issue, etc.

*Solution*

Deprecated features can each be given an identifier (ID, String, etc). Use
of a deprecated feature can go to a specific log within the component or
general puppet logs that includes the timestamp, identifier, and relevant
identifying information such as catalog or configuration file name and
line. An additional tool can be provided for users to review this log and
provide the number of and last timestamp indicating usage of the deprecated
feature, along with the entirety of that log entry.

Each deprecated feature identifier can easily be searched for in Puppet
Labs documentation, Jira tickets, and search engines to help determine how
a user may address the issue prior to upgrades. After an upgrade where a
deprecated feature is removed, the identifier can be displayed directly to
a user in addition to the log, and any interactive upgrade can review the
recent logs (i.e. 24 or 48 hours) and highlight features removed in the the
last MAJOR or MINOR update.

It is understood that newer versions that do not support a feature will
also no longer be able to detect the deprecated feature and provide
accurate logging of the missing feature that is causing the fault. By
separating out the deprecated messages into a separate log and providing a
simple tool to search the logs, the user is empowered to easily find the
use of the deprecated features and can correlate the IDs with release notes
and such as well as the time of upgrades.

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT90BqJTQHxga8nzTHTLoyV%3DjpLJ5BOOgDOjXHcN9dpiMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Signal boost on HI-490 - moving hiera.yaml out of codedir

[Rob Nelson]

Ah, I misunderstood Eric's response to Eli then. Well as long as the
location is the same regardless of edition and only varies by version (I.e.
$::puppetversion >= 4.5.0 or similar) it shouldn't muck things up too much.

On Tuesday, March 15, 2016, R.I.Pienaar <r...@devco.net> wrote:

>
>
> On 15 Mar 2016, at 02:13, Rob Nelson <rnels...@gmail.com
> <javascript:_e(%7B%7D,'cvml','rnels...@gmail.com');>> wrote:
>
> I've not seen a conflict with r10k, can you elaborate on that? Curious if
> I'm hitting it and not knowing it!
>
> However, I have seen it cause great confusion with modules like
> hunner/hiera or jlambert121/puppet that want to manage it, because there's
> an ugly set of possible locations depending on oss vs enterprise and then
> various versions. There have been a LOT of changes in the location and
> adding another possible location to everyone's module matrix seems like it
> may make the problem worse. So when it comes to timing, where it's at now
> seems like a reasonable location until such time as per environment hiera
> configs are available, IMHO.
>
>
> Per environment configs have been around for a bit in 4. Some bug fixes
> should land in next and then they should be totally usable I think
>
>
>
> On Monday, March 14, 2016, Eric Sorenson <eric.soren...@puppetlabs.com
> <javascript:_e(%7B%7D,'cvml','eric.soren...@puppetlabs.com');>> wrote:
>
>> As a result of some introspection around r10k workflows, I came to agree
>> with the statement in the title of HI-490: "the location of hiera.yaml in
>> puppet-agent is a mistake." The root of the problem is that the current
>> hiera.yaml is a mixture of global configuration (datadir location, merge
>> behaviour, the backend configuration) and "code" like settings, namely the
>> hierarchy itself. We chose to put it in $codedir but this has caused
>> problems when people try to manage the file with puppet modules because it
>> then conflicts with the control repo/r10k deploy workflow. (The PE-13367
>> ticket I mention in the description there is about the file sync service,
>> but more generally r10k+webook management runs into the same problem.)
>>
>> There was some conversation that spun off into a google doc and seemed to
>> coalesce around the following proposal:
>>
>> 1. puppet-agent packaging would be updated to install a default
>> hiera.yaml at $confdir/hiera.yaml
>> 2. both puppet and hiera would check in the old location,
>> $codedir/hiera.yaml, and fall back to the new location
>> $confdir/hiera.yaml
>> 3. we would document the new location and encourage users to move their
>> hiera.yaml
>>
>> This then raises the question of when we yank support for the old
>> location, $codedir/hiera.yaml. Here the suggestion is:
>> 1. for puppet-agent this happens in a major release of
>> puppet/hiera/puppet-agent
>> 2. for Puppet Enterprise additionally, we check if there is a
>> $codedir/hiera.yaml and block the upgrade if it exists
>>
>> I wanted to raise visibility on this and see what the wider puppet-dev
>> audience thought. Please feel free to chime in here or on the ticket and
>> I'll summarize before taking any action.
>>
>>
>> --eric0
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/55526912-dd49-4fca-8ec6-2f59da7eca84%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-dev/55526912-dd49-4fca-8ec6-2f59da7eca84%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Rob Nelson
> rnels...@gmail.com <javascript:_e(%7B%7D,'cvml','rnels...@gmail.com');>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAC76iT9vRzLe9NyXusmxcXXRE7ZVyE181rnrers8K9qjVoLCjQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CAC76iT9vRzLe9NyXusmxcXXRE7ZVyE181rnrers8K9qjVoLCjQ%40mail.gmail.com?utm_medium=email_source=foo

Re: [Puppet-dev] Re: End of Life estimate for Puppet 3.X?

[Rob Nelson]

I know it's long past EOL/EOS but could you add in Puppet 2 at that URL?
The only EOS notice I could find is in a mailing list entry and it would be
nice to have a more official reference to it for doubters.


Rob Nelson
rnels...@gmail.com

On Mon, Mar 14, 2016 at 2:18 PM, Eric Sorenson <eric.soren...@puppetlabs.com
> wrote:

> Yep, believe me it's under active discussion and we'll shout from the
> rooftops once everything's sorted; part of the reason for the extension was
> that we realised July was too close for comfort for a lot of customers.
>
> --eric0
>
> On Mar 14, 2016, at 11:16 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
> wrote:
>
> Got it. Thanks Eric!
>
> Please remember that a lot of places have a 30 to 90 day mandate to get
> off of unsupported versions of software. Announcing this everywhere
> possible as early as possible would be great so that the big machinery can
> get moving.
>
> Thanks,
>
> Trevor
>
> On Mon, Mar 14, 2016 at 2:05 PM, Eric Sorenson <
> eric.soren...@puppetlabs.com> wrote:
>
>> Hey Trevor, I'll reply over on the users list as well, but here it is: As
>> a practical matter we're going to have Puppet 3.8 on maintenance and
>> security fixes as long as there's a supported PE version that incorporates
>> it. The support lifecycle website[1] currently says July 2016 but we're
>> highly likely to extend this through the end of December 2016.
>>
>> [1] https://puppetlabs.com/misc/puppet-enterprise-lifecycle
>>
>> On Monday, March 14, 2016 at 6:52:51 AM UTC-7, Trevor Vaughan wrote:
>>>
>>> Hi All,
>>>
>>> Sorry about the bad form but I popped this over on Users without any
>>> response for a week.
>>>
>>> Is there a current EOL estimate for the 3.X series? I've been seeing
>>> some confusion with PE 3.8 and FOSS 3.8.
>>>
>>> Thanks,
>>>
>>> Trevor
>>>
>>> --
>>> Trevor Vaughan
>>> Vice President, Onyx Point, Inc
>>> (410) 541-6699
>>>
>>> -- This account not approved for unencrypted proprietary information --
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/3571018a-7ebd-4dae-ba1c-9b7ea937b61e%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-dev/3571018a-7ebd-4dae-ba1c-9b7ea937b61e%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXBnjAz%3D9Eo0Wga3tY2kovnfNAOhQQWGfy14zPDN%2B0MEw%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXBnjAz%3D9Eo0Wga3tY2kovnfNAOhQQWGfy14zPDN%2B0MEw%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0
> puppet platform // coffee // techno // bicycles
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/FE598686-561E-4250-9BFC-703AB91ADAF3%40puppetlabs.com
> <https://groups.google.com/d/msgid/puppet-dev/FE598686-561E-4250-9BFC-703AB91ADAF3%40puppetlabs.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9HXxq1ZmWRike7rYGnbk-e2uJzAYVVs9F6u3NE8akAkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] PUP-5296

[Rob Nelson]

Fwiw, I'm not seeing this in any modules on EL7, I assume because all the
packages I use support systemd, so it may not be that widespread across EL7
users.

On Sunday, March 13, 2016, Alex Harvey <alexharv...@gmail.com> wrote:

> Hi all,
>
> I have just discovered the bug PUP-5296 using the latest Puppet 4 and the
> Puppet Labs CentOS 7 vagrant box.
>
> This bug, reported 6 months ago, breaks idempotence in any module that
> tries to use an Init-style service in the wonderful world that is Systemd.
> E.g.
>
> [root@centos-72-x64 ~]# puppet apply /tmp/apply_manifest.pp.ZEj2Kr
> Notice: Compiled catalog for centos-72-x64.wg.dir.telstra.com in
> environment production in 2.10 seconds
> Notice: /Stage[main]/Kibana4::Service/Service[kibana4]/enable: enable
> changed 'false' to 'true'
> Notice: Applied catalog in 18.70 seconds
>
> [root@centos-72-x64 ~]# puppet apply /tmp/apply_manifest.pp.ZEj2Kr
> Notice: Compiled catalog for centos-72-x64.wg.dir.telstra.com in
> environment production in 2.26 seconds
> Notice: /Stage[main]/Kibana4::Service/Service[kibana4]/enable: enable
> changed 'false' to 'true'
> Notice: Applied catalog in 18.61 seconds
>
> A workaround might be to raise a PR to add optional provider overrides for
> every module in the world that tries to manage a SysV style service on a
> platform.
>
> But the bug report indicates that we already know what the fix is for this
> bug?  Can't we just fix it?
>
> Thanks,
> Alex
>
> --
> Partner
> RAZOR Consulting
> t: +61 409 665 227
> w: http://razorconsulting.com.au
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/47bb57e7-30ef-4494-8230-c326829f740d%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/47bb57e7-30ef-4494-8230-c326829f740d%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT_bbcugs7UTxjS%2BmqRMi3JYC%3DqYM9JSYsd8-WZ56RW-rQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Facter config file

[Rob Nelson]

On Tuesday, March 1, 2016, Matthew Gaspar <gat...@gmail.com> wrote:

> The only problem I sometimes encounter, which may be a usage issue on my
> part, is when creating custom facts sometimes it'd be nice to just run
> `facter my_custom_fact` to get the output. If there would be some way to
> register custom facts so that facter picks them up without having to run
> puppet or run the ruby code the custom fact is in manually, that would be
> interesting. If that already exists I haven't found how to do that.
>

This probably isn't in scope for this, but the above is my most highly
sought after goal.


> Either way, I think a config where you can either specify which facts to
> enable or disable would be useful.
>

We manage firewalls and routers as well as server OSes and it would be nice
to flag which facts shouldn't cause errors on every run on those nodes. I
would suggest this information should be available locally AND/OR through
the master/agent mechanism somehow - please don't require yet another
file{} resource for puppet related settings in every node's manifest.


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT-eEdup-%3DM2jJH-8-_GFj4EywQjX%2BihaS%2BLhgC8_9di_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] How strict do you want puppet to be?

[Rob Nelson]

Per module path would be good for site modules, but not great for forge
modules. Maybe both could be supported.

On Tuesday, February 23, 2016, Ryan Whitehurst <r...@puppetlabs.com> wrote:

> On Tue, Feb 23, 2016 at 3:22 PM, Walter Heck <walterh...@olindata.com
> <javascript:;>> wrote:
> > On Tuesday, February 23, 2016 at 11:31:18 PM UTC+1, Ben Ford wrote:
> >>
> >> Would it be possible in this scheme to mark strict mode per class? I
> could
> >> mark my own code as being strict and therefore get compile time failures
> >> when I make a typo myself, but wouldn't have to enforce that on all
> third
> >> party code.
> >
> >
> > Instead of per class I'd like to be able to set it per (module)path. We
> use
> > r10k and split the role and profile modules to their own modulepath
> > (typically called 'site'), all 3rd party modules live in the standard
> > modulepath.
> >
> > I could also imagine people wanting to set this per environment.
> >
> > Lastly, I think --strict=ignore should be --strict=off, but that's
> personal
> > preference.
>
> I agree with everything Walter is saying here. Per-class would be
> difficult, but if there was a way to set it per-modulepath, you could
> accomplish what Ben is asking for. It should also definitely be an
> available setting in environment.conf.
>
> --strict=off seems a bit nicer to me as well than does
> --strict=ignore, but I don't care much.
>
> My first thought is that --strict=warn would make a sensible default
> in this scenario, as it's most similar to puppet's traditional
> behavior of showing deprecation warnings every time.
>
> > great idea, hope to see it come to life sooner rather then later :)
> >
> > cheers,
> >
> > Walter
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to puppet-dev+unsubscr...@googlegroups.com <javascript:;>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-dev/6c8709a0-30ae-43d8-b558-3819b4b5dd85%40googlegroups.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com <javascript:;>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAHTHiAE8pFAA-O0Zf6d_MJrgiyxqw72s_YcXizHAe%3Di9-2vBzg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8j2zPV-FBn1QNiZ6L-C1-NjoUHgeETWOHiZRqWT7M_xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] RFC - A specification for module schemas

[Rob Nelson]

Those three types will be the majority of what you use, sure, but Optional
and Enum are awesome. Pattern seems potent but may be difficult to use.
Check out how this module uses the type system:
https://github.com/jlambert121/jlambert121-puppet/blob/master/manifests/init.pp

On Monday, February 1, 2016, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:

> I'll give it a shot again (unfortunately, I have legacy 3.X users so
> updating to use 4.X features will take some time).
>
> Honestly, I still haven't found a compelling reason for anything besides
> Booleans, Undef, and Strings. Even the stdlib code converts everything to a
> string due to the issues with dealing with Strings and Numbers together.
>
> Are there any compelling cases that I'm missing out there?
>
> Happy to fork this to a different thread.
>
> Trevor
>
> On Mon, Feb 1, 2016 at 4:58 PM, Eli Young <elysc...@gmail.com
> <javascript:_e(%7B%7D,'cvml','elysc...@gmail.com');>> wrote:
>
>> On Mon, Feb 1, 2016 at 11:48 AM, Trevor Vaughan <tvaug...@onyxpoint.com
>> <javascript:_e(%7B%7D,'cvml','tvaug...@onyxpoint.com');>> wrote:
>>
>>> I would *love* to see something like this hit the core language, but
>>> there are quite a few cases where I have items that can be a Boolean,
>>> Number, or String (I'm still not loving needing to convert Numbers to
>>> Strings everywhere for consistency) so it gets difficult to use the Puppet
>>> 4 inbuilt validators.
>>>
>>
>> That's where Variants come in:
>> https://docs.puppetlabs.com/puppet/4.2/reference/lang_data_abstract.html#variant
>>
>> Variant[Boolean, Number, String] means "must be a Boolean, a Number, or a
>> String", which sounds like exactly what you want.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com
>> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
>> .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CAE%2BtgeMbfHhRC76XJ%2BKz0czJsiazgfadQ%2BJ0oU3%3Di9sKtu_fGw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CAE%2BtgeMbfHhRC76XJ%2BKz0czJsiazgfadQ%2BJ0oU3%3Di9sKtu_fGw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
>
> -- This account not approved for unencrypted proprietary information --
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWKSv2P-yOMD1kzfPYima_KVwzbyTRt6ToaejxqyLebYA%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWKSv2P-yOMD1kzfPYima_KVwzbyTRt6ToaejxqyLebYA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8n_u8FEhuvjnXFNNtaFPiY5EUTUQZkGUp%2BFZAr42kWxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] travis issue affecting many repos using ruby 1.9.3

[Rob Nelson]

Do you know what's triggering it? That doesn't seem like a new issue, and I
see some 1.9.3 builds working without that, such as
https://travis-ci.org/voxpupuli/puppet-confluence/builds/106194437


Rob Nelson
rnels...@gmail.com

On Mon, Feb 1, 2016 at 12:38 PM, Corey Osman <co...@logicminds.biz> wrote:

> FYI
>
> There is an issue with travis and bundler on ruby version 1.9.3.  So if
> your build matrix uses this ruby you may be seeing this error: NoMethodError:
> undefined method `spec' for nil:NilClass
>
> To fix you just need to update bundler like so in your travis file.
>
>
> before_install:
>   # https://github.com/bundler/bundler/issues/3558
>   gem update bundler
>
>
>
>
> Corey
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/7B821AF7-553B-4C6E-BB5D-4907CE171B77%40nwops.io
> <https://groups.google.com/d/msgid/puppet-dev/7B821AF7-553B-4C6E-BB5D-4907CE171B77%40nwops.io?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8xjyPhPP0XTW%3DFyRssDX%2BL9K6iYAYwZGm6XAguSHZLug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Rob Nelson]

Ruby 1.9.3 is available in the Software Collections (SCL) repository.
Instructions at
https://digitalchild.info/centos-6-5-and-ruby1-9-3-via-software-collections/
.

There may be some side effects for any system utilities that expect 1.8.7
but that's a risk you'll have to accept if you're still on EL6, just like
every other ancient version of software it includes. It does "work" in most
senses, though.

On Friday, January 29, 2016, Alex Harvey <alexharv...@gmail.com> wrote:

> https://bugs.centos.org/view.php?id=10268
>
> On Friday, January 29, 2016 at 4:15:16 PM UTC+11, Alex Harvey wrote:
>>
>> I thought I'd just put it out there that it's the Year of Our Lord 2016*
>> and CentOS is still installing Ruby 1.8.7, and yum.puppetlabs.com is
>> still not providing a modern Ruby either.
>>
>> Yes, PE provides a Ruby.
>> Yes, Puppet 4 provides a Ruby.
>> Yes, Puppet-omnibus can build a Ruby.
>> Yes, RVM is kinda cool.
>> Yes, compiling Ruby is kinda fun sometimes.
>>
>> But, as a user, I want to type "yum install ruby" and, OMFG, ruby
>> installs.
>>
>> *With apologies to adherents of other religious faiths and proponents of
>> Lunar and non-Gregorian calendars.
>>
>> :)
>>
>> On Friday, July 26, 2013 at 1:13:24 AM UTC+10, Christian Flamm wrote:
>>>
>>> Hi,
>>> I'm (using CentOS 6.4 and I'm) suffering from an AFAIU
>>> performance/design bug (http://projects.puppetlabs.com/issues/20865)
>>> which (althoughit's not recommended as a work-around) does not occur when
>>> using Ruby-1.9.3 (Yaeh!) instead of Ruby-1.8.7. I just can't find a public,
>>> well-known, well-maintained repository (I can't find any, actually) that
>>> offers it as an EL6 RPM.
>>>
>>> I know one can install different ruby versions with *rvm*. My problems
>>> with this approach are (similar issues with compiling from source):
>>>
>>>- *rvm* and *yum* (the way Ruby is currently installed) are tools
>>>that AFAIK don't care/know about each other
>>>- *gem* (I guess I'd have to use *gem *then to install puppet?) and
>>>*yum* (the way puppet and puppet-server packages are currently
>>>installed) are tools that AFAIK don't care/know about each other
>>>- Because not caring/knowing about each other - Can one tool harm
>>>(e.g. partially override?) software/files installed by the other tool?
>>>- Which Ruby do I start, when typing *ruby *into a console... same
>>>for *puppet*. Which of these "rivaling" tools (*rvm* vs. *yum*, *gem*
>>>vs. *yum) *has control over e.g. $PATH order?
>>>
>>> That's why I would prefer a Ruby-1.9.3 RPM that I could install (clean
>>> update over 1.8.7) which in addition works fine with RPM packages (e.g.
>>> puppet-server-xxx.el6.noarch.rpm, puppet-xxx.el6.noarch.rpm) from
>>> yum.puppetlabs.com.
>>>
>>> Naive question: Why don't you provide one in yum.puppetlabs.com :-) ?
>>>
>>> Christian
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com
> <javascript:_e(%7B%7D,'cvml','puppet-dev%2bunsubscr...@googlegroups.com');>
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/0c859244-321e-4560-ba5e-15ebe2fff962%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-dev/0c859244-321e-4560-ba5e-15ebe2fff962%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8uDUum_PV3VX7Mo7HC9p%3Ds5vd-toaORtWxYbVf5L%2Bc2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Rob Nelson]

SCL upstream comes from the vendor (
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.0_Release_Notes/index.html#appe-Documentation-1.0_Release_Notes-Revision_History)
so that sounds like the best solution in this case. Even if you move to
EL7, it provides Ruby 2.0.0 whose maintenance ends next month (
https://www.ruby-lang.org/en/news/2015/02/25/ruby-2-0-0-p643-is-released/)
and you still have to go to SCL for Ruby 2.2. EL's support timeframe is the
worst.


Rob Nelson
rnels...@gmail.com

On Fri, Jan 29, 2016 at 8:31 AM, Alex Harvey <alexharv...@gmail.com> wrote:

> Thanks for the heads up.  Anything less than Puppet Labs providing a
> working Ruby at yum.puppetlabs.com, or CentOS providing one, feels to me
> like a bit of a hack.  I've seriously got a customer wanting to ditch
> Puppet and go to Ansible because because they just want it to be easy to
> install open source Puppet 3.  We were burnt by Puppet Omnibus.  It just
> feels a bit like Puppet's giving us the finger, when all it would take is
> someone to stick an RPM on a server.  This problem could have been solved
> years ago, as the original poster in this thread suggested.
>
> On Friday, January 29, 2016 at 10:38:29 PM UTC+11, Rob Nelson wrote:
>>
>> Ruby 1.9.3 is available in the Software Collections (SCL) repository.
>> Instructions at
>> https://digitalchild.info/centos-6-5-and-ruby1-9-3-via-software-collections/
>> .
>>
>> There may be some side effects for any system utilities that expect 1.8.7
>> but that's a risk you'll have to accept if you're still on EL6, just like
>> every other ancient version of software it includes. It does "work" in most
>> senses, though.
>>
>> On Friday, January 29, 2016, Alex Harvey <alexh...@gmail.com> wrote:
>>
>>> https://bugs.centos.org/view.php?id=10268
>>>
>>> On Friday, January 29, 2016 at 4:15:16 PM UTC+11, Alex Harvey wrote:
>>>>
>>>> I thought I'd just put it out there that it's the Year of Our Lord
>>>> 2016* and CentOS is still installing Ruby 1.8.7, and yum.puppetlabs.com
>>>> is still not providing a modern Ruby either.
>>>>
>>>> Yes, PE provides a Ruby.
>>>> Yes, Puppet 4 provides a Ruby.
>>>> Yes, Puppet-omnibus can build a Ruby.
>>>> Yes, RVM is kinda cool.
>>>> Yes, compiling Ruby is kinda fun sometimes.
>>>>
>>>> But, as a user, I want to type "yum install ruby" and, OMFG, ruby
>>>> installs.
>>>>
>>>> *With apologies to adherents of other religious faiths and proponents
>>>> of Lunar and non-Gregorian calendars.
>>>>
>>>> :)
>>>>
>>>> On Friday, July 26, 2013 at 1:13:24 AM UTC+10, Christian Flamm wrote:
>>>>>
>>>>> Hi,
>>>>> I'm (using CentOS 6.4 and I'm) suffering from an AFAIU
>>>>> performance/design bug (http://projects.puppetlabs.com/issues/20865)
>>>>> which (althoughit's not recommended as a work-around) does not occur when
>>>>> using Ruby-1.9.3 (Yaeh!) instead of Ruby-1.8.7. I just can't find a 
>>>>> public,
>>>>> well-known, well-maintained repository (I can't find any, actually) that
>>>>> offers it as an EL6 RPM.
>>>>>
>>>>> I know one can install different ruby versions with *rvm*. My
>>>>> problems with this approach are (similar issues with compiling from 
>>>>> source):
>>>>>
>>>>>- *rvm* and *yum* (the way Ruby is currently installed) are tools
>>>>>that AFAIK don't care/know about each other
>>>>>- *gem* (I guess I'd have to use *gem *then to install puppet?)
>>>>>and *yum* (the way puppet and puppet-server packages are currently
>>>>>installed) are tools that AFAIK don't care/know about each other
>>>>>- Because not caring/knowing about each other - Can one tool harm
>>>>>(e.g. partially override?) software/files installed by the other tool?
>>>>>- Which Ruby do I start, when typing *ruby *into a console... same
>>>>>for *puppet*. Which of these "rivaling" tools (*rvm* vs. *yum*,
>>>>>*gem* vs. *yum) *has control over e.g. $PATH order?
>>>>>
>>>>> That's why I would prefer a Ruby-1.9.3 RPM that I could install (clean
>>>>> update over 1.8.7) which in addition works fine with RPM packages (e.g.
>>>>> puppet-server-xxx.el6.noarch.rpm, puppet-xxx.el6.noarch.rpm) f

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Rob Nelson]

The ruby 1.8.7 that comes with EL6 and 2.0.0 with EL7 work fine. The vendor
offers 1.9.3 and 2.2.0 in their SCL repos, respectively. What specifically
is the problem that the "too many yaks to shave" complaints are referencing
that the vendor's base and SCL repos do not address?

This is a sincere question! It "works on my machine" but I only use Ruby
for Puppet itself, no applications rely on it, so I'm sure my experience is
pretty narrow and I'd really like to understand.


Rob Nelson
rnels...@gmail.com

On Fri, Jan 29, 2016 at 11:16 AM, Alex Harvey <alexharv...@gmail.com> wrote:

> Yep, it's solved in Puppet 4 - the all-in-one package is fantastic, as is
> so much in Puppet 4.  However PE hasn't release Puppet 4 yet; my assessment
> of the Puppet Forge is that not many modules out there are ready; and I am
> not super confident that other tools in the ecosystem like Beaker,
> Librarian etc are ready; so I am not personally willing to recommend Puppet
> 4 to customers at this stage.  In any case, loads and loads of people will
> be using Puppet 3 for a long, long time yet.
>
> And then I get back to - why not just put the RPMs in the yum repository?
> They're already in PE aren't they?  I get it that it's not really Puppet's
> problem that EL is crap, but on the other hand, it actually is.  Puppet
> made the choice to build a DSL on Ruby.  So, when I discovered earlier
> today that there's still no supported Ruby for the latest Puppet 3 for
> CentOS Linux, I couldn't believe it.  This is RUBY on EL6/7.  This is not a
> wacky feature request.  Without Ruby, the amazingly complex, feature rich
> ecosystem we know and love as Puppet is a castle built on sand.
>
> It shouldn't be so hard to stand Puppet up in 2016.  I love Puppet, and I
> love Ruby, and I hate hearing super smart developers telling me that Salt
> or Ansible are superior, when their main reason for saying so is that Ruby
> and Puppet together are just way too many yaks to shave.  And I hear this,
> all, the, time.
>
> On Saturday, January 30, 2016 at 12:39:15 AM UTC+11, Erik Dalén wrote:
>>
>> Isn't this already solved with the Puppet 4.x packaging (puppet-agent)?
>> So why insist on installing an old Puppet version instead of a modern one?
>>
>> Personally I prefer that PuppetLabs is developing new features in Puppet
>> 4.x instead of spending time improving packaging and stuff for Puppet 3.x.
>>
>> On Fri, 29 Jan 2016 at 14:31 Alex Harvey <alexh...@gmail.com> wrote:
>>
>>> Thanks for the heads up.  Anything less than Puppet Labs providing a
>>> working Ruby at yum.puppetlabs.com, or CentOS providing one, feels to
>>> me like a bit of a hack.  I've seriously got a customer wanting to ditch
>>> Puppet and go to Ansible because because they just want it to be easy to
>>> install open source Puppet 3.  We were burnt by Puppet Omnibus.  It just
>>> feels a bit like Puppet's giving us the finger, when all it would take is
>>> someone to stick an RPM on a server.  This problem could have been solved
>>> years ago, as the original poster in this thread suggested.
>>>
>>> On Friday, January 29, 2016 at 10:38:29 PM UTC+11, Rob Nelson wrote:
>>>
>>>> Ruby 1.9.3 is available in the Software Collections (SCL) repository.
>>>> Instructions at
>>>> https://digitalchild.info/centos-6-5-and-ruby1-9-3-via-software-collections/
>>>> .
>>>>
>>>> There may be some side effects for any system utilities that expect
>>>> 1.8.7 but that's a risk you'll have to accept if you're still on EL6, just
>>>> like every other ancient version of software it includes. It does "work" in
>>>> most senses, though.
>>>>
>>>> On Friday, January 29, 2016, Alex Harvey <alexh...@gmail.com> wrote:
>>>>
>>>>> https://bugs.centos.org/view.php?id=10268
>>>>>
>>>>> On Friday, January 29, 2016 at 4:15:16 PM UTC+11, Alex Harvey wrote:
>>>>>>
>>>>>> I thought I'd just put it out there that it's the Year of Our Lord
>>>>>> 2016* and CentOS is still installing Ruby 1.8.7, and
>>>>>> yum.puppetlabs.com is still not providing a modern Ruby either.
>>>>>>
>>>>>> Yes, PE provides a Ruby.
>>>>>> Yes, Puppet 4 provides a Ruby.
>>>>>> Yes, Puppet-omnibus can build a Ruby.
>>>>>> Yes, RVM is kinda cool.
>>>>>> Yes, compiling Ruby is kinda fun sometimes.
>>>>>>
>>>>>> But, as a user, I want to type "yum install ruby

Re: [Puppet-dev] Re: ruby-1.9.3 in yum.puppetlabs.com

[Rob Nelson]

On Fri, Jan 29, 2016 at 12:08 PM, Alex Harvey <alexharv...@gmail.com> wrote:

> The main issue I still have, and I just checked again, is that too many
> Forge modules say in their documentation that they're only supporting
> Puppet 3.  E.g. Logstash, Nginx.  Now, maybe in actual fact they work fine
> in Puppet 4; and that was mostly my experience when I played with it.  But,
> you know, if someone's crazy Forge module doesn't work, users point the
> finger at Puppet for that.


While you can't force all the forge modules to be updated, I highly suggest
setting up rspec-puppet on your controlrepo. You'll find the modules that
don't support future parser with 3, or 4 in general, and file tickets with
the module authors. I had to do that for a number of modules I use
(ajjahn/dhcp and stahnma/epel ring a bell) and I found the authors are
generally receptive. If they're not, then it might be a good indicator that
you shouldn't be relying on that module; find another or fork it if the
license allows you to.

Heck, maybe some module authors are watching this thread and are seeing the
demand for supporting Puppet 4 :)


Rob Nelson
rnels...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9O6pofNB2%3DrWGu34%3DZaGkSVrcEhgO7EBGWUYd6pwUZ_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] hiera_hash in parameter lookup

[Rob Nelson]

Corey, take a look at the lookup_options to specify merge behavior with
APL. Prior to this, APL would not do hash lookups with any merge behavior.
This should change that:
https://docs.puppetlabs.com/puppet/latest/reference/lookup_quick.html#specifying-merge-behavior
and
https://docs.puppetlabs.com/puppet/latest/reference/function.html#merge-behaviors
for the valid options.


Rob Nelson
rnels...@gmail.com

On Wed, Jan 27, 2016 at 1:07 PM, Corey Osman <co...@logicminds.biz> wrote:

> I have the following code which uses the auto binding feature to lookup a
> hiera value.  This is nothing new though. The problem I see is that there
> is no way to tell puppet to use hiera_hash() for the install_options.
>
> class sql2014(
>   Hash   $install_options= {},
>   String $instance_name  = 'MSSQLSERVER',
>   Hash $ssdt_install_options = {}
> )
>
> Now I could alternatively specify hiera_hash but then I create a race
> condition unless I change the key name:
>
> class sql2014(
>   Hash   $install_options= hiera_hash(’sql2014::install_options’,
> {}),
>   String $instance_name  = 'MSSQLSERVER',
>   Hash $ssdt_install_options = {}
> )
>
> Please tell me that when using puppet 4 data types, puppet will
> automatically switch hiera methods based on type to use the hiera hash /
> array binding method instead of the normal hiera method.
>
> If not, is this even possible?
>
>
> Corey
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/2C87F17D-1E11-4CD7-A65B-8F4B4EB2E90E%40nwops.io
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT9PKsesuOMHnBwt2g%2BnAh22Ytdy%2B948OVs6yaUVrc_wdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev] rspec-puppet 2.3.2

[Rob Nelson]

David, and all the others who worked on this, thanks for the quick response
and the effective fix!


Rob Nelson
rnels...@gmail.com

On Tue, Jan 26, 2016 at 12:44 PM, David Schmitt <
david.schm...@puppetlabs.com> wrote:

> Hi,
>
> over the weekend there was a situation where the newest puppet versions
> (3.8.5 and 4.3.2) would interact badly with the latest version of
> rspec-puppet (2.3.0).
>
> Yesterday I uploaded 2.3.1 to fix the issue with 3.8.5 and today there is
> 2.3.2 to completely fix this across all puppet versions.
>
> If you ran into errors like
>
> NoMethodError: undefined method `resource' for nil:NilClass
>>
>
> or
>
> Unsupported data type: 'Symbol' on node ...".
>>
>
> please retry with the rspec-puppet 2.3.2.
>
> Apologies for any inconvenience.
>
> David
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CALF7fHZmXxdkfUZzxpu-HqGukU-7%2BRf%2BwehUNyobY8wxwgE1oQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CALF7fHZmXxdkfUZzxpu-HqGukU-7%2BRf%2BwehUNyobY8wxwgE1oQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAC76iT8ANTgDMEC3ejy3NoswQ5JcTXxwV%3DFm53gGRVN%3DmM5LzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re: The host type has unexpected behavior and is not idempotent

[Rob Nelson]

My concern is with accurate modeling of existing state. For example:

[rnelson0@test ~]$ cat /etc/hosts
# HEADER: This file was autogenerated at Thu Jan 22 22:08:17 + 2015
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1   localhost   localhost.localdomain localhost4 localhost4.
localdomain4
::1 localhost   localhost.localdomain localhost6 localhost6.
localdomain6

1.2.3.4 test
::0001 test
[rnelson0@build profile]$ puppet resource host
host { 'localhost':
  ensure   = 'present',
  host_aliases = ['localhost.localdomain', 'localhost4', 
'localhost4.localdomain4'],
  ip   = '127.0.0.1',
  target   = '/etc/hosts',
}
host { 'test':
  ensure = 'present',
  ip = '1.2.3.4',
  target = '/etc/hosts',
}

Puppet cannot accurately model the existing state, so it is difficult at 
beast to enforce that state. There are so many edge cases that I feel it 
may be impossible, but I don't think we've identified them all, much less 
tested them. Regardless, such a simple hosts file should be enumerable as 
an accurate model.

I do not have any good answers for this issue, but wanted to point out what 
I think is a good guiding principle for resolving this. Perhaps picking a 
single OS, a HostEntry type/provider can be built to try and accurately 
model state, whether the namevar is the ip, hostname, or something else, 
until we get it right. As a new type, there would be no deadline for Puppet 
4 and hence it could be done right rather than making compromises again.


On Monday, January 26, 2015 at 8:06:33 PM UTC-5, Eli Young wrote:

 As per PUP-3901 https://tickets.puppetlabs.com/browse/PUP-3901, the 
 host type has some serious issues.  Major issues with the current design:

1. The namevar:
- It's currently the canonical hostname. This means that a hostname 
   can be the canonical representation for at most 1 IP address.  This is 
 a 
   problem if, for example, you want to provide both IPv4 and IPv6 
 addresses 
   for a hostname.
   - Changing it to be the IP address would mean that an IP address 
   could have at most one canonical hostname associated with it.  This is 
 less 
   of an issue, but still not ideal.
   - Probably the best solution here is to change this to be both the 
   IP address and the canonical hostname (e.g. 1.2.3.4/example.com). 
   However...
2. Parsing is flawed:
- Multiple records with the same value for the namevar (currently the 
   canonical hostname) overlap and only one is registered.  Modifying or 
   removing records that overlap behaves inconsistently and, in the case 
 of 
   removal, requires multiple runs to achieve consistency.  Examples in 
 the 
   issue's description.
   - Changing the namevar to be the IP address or both the IP address 
   and the canonical hostname could cause problems on Windows, where the 
   number of hostname aliases per record is limited. This could be 
 resolved by 
   having the provider split a resource into multiple records in the file 
 if 
   the underlying system has alias count limits.

 The other issues are all consequences of these two issues:

1. Inconsistent resource modification and removal (examples in the 
issue's description) is a result of namevar collision.
2. Removal of a hostname causing removal of all the aliases is more of 
a documentation issue than anything. So long as this is explicitly called 
out as expected behavior, it's not a problem.

 As such, my proposed changes to the host type are to:

1. Change the generated resource namevar (and, by extension, the alias 
for specified resources) to use both the IP address and the canonical 
hostname.
2. Fix parsing to handle cases where multiple records specify the same 
namevar (which, after change #1, would be an IP address and canonical 
hostname) by merging them into a single resource.
3. Update documentation to to indicate that the hostname aliases are 
not first-class host items and that, when a hostname is removed, all 
aliases are removed too.  If the user wants to retain a hostname alias 
while removing a hostname, they'll need to put it into a different host 
resource.
4. To allow manifests to set relationships to hosts without knowing 
ahead of time what the IP address is, potentially provide resource aliases 
with titles set to the hostname and all the hostname aliases. 
Unfortunately, this runs into an issue when multiple host resources 
 service 
the same hostname; blindly making resource aliases would result in each 
trying to alias to the same name, but conditionally aliasing based on if 
 an 
alias already exists would result in a relationship attaching to different 
host resources depending on parse order.  This is a problem that I'm not 
sure how to solve.

 Furthermore,