Re: [Puppet Users] Re: Making a "role" fact work

[Jason Slagle]

On 1/29/16, 11:14 AM, "Gareth Humphries"  wrote:

Normally, yes, but in this case it needs a class list locally to populate the 
fact, and it doesn't have that until after a run.
Facts get sent to the master, where classes are allocated and a catalog 
compiled, then the catalog sent back to the client.  Without the initial 
catalog, the client has no knowledge of the classes, and can't set the fact 
accordingly.

If I could set the fact on the server I'd be away, but I haven't yet found a 
way to get that working.


This is proving harder than initially thought.  I think I might have to shelve 
it.   :-(

I’m also having a hard time understanding the end goal.

It seems like you have information based on the classes assigned to a host that 
determine it’s role.  You want to use those classes to set a role fact on the 
node.

What I don’t understand is that if you have a defined set of logic you can 
apply to determine the role, who you need a role fact at all?  What in the 
classes is required for you to determine this?

Jason

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/D3737985-FEE6-4DF2-878C-E2D94C8CE156%40tacorp.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

[Jason Slagle]

On 6/23/15, 9:03 PM, "Eric Sorenson"  wrote:

>
>> I suspect this confusion will hinder deployment ­ the AIO packaging is
>> certainly in the cons category for us.
>
>I really want to understand this, because it's a big deal. (My life goal
>at 
>this point is to get as many people as possible upgraded to Puppet 4, so
>anything that gets in the way of that is a problem!) There's been a bunch
>of 
>different points in the thread, some of them about the numbering and some
>about the packaging itself; what would reduce the confusion for you?

It’s actually interesting, because it came up at a PUG meeting here
locally, and I definitely got a more negative than positive vibe from the
AIO packaging, as well as my own feelings.

In the end, it comes down to the potential security implications for some
of my clients.  On the enterprise front, you provide an installer, which
you have a contractual obligation to support.  When security issues arise
with say the bundled ruby, you are going to quickly act on them.

On the open source side, I’m less sure about that obligation.  You guys
have been spectacular at keeping up with security patches, but when you
decide to deprecate 4.1, you’ll have people with it installed 2 years from
now.  You now have a much larger software ecosystem to worry about
vulnerabilities in.  Basically, it puts the open source users in a
position where they have to rely on puppetlabs for patches to upstream
projects such as the bundled ruby or openssl on the agent side.

A related concern comes with companies with infosec departments that have
to bless things.  I get Ruby 2.1.0 blessed, but then the bundled ruby gets
updated to 2.1.1.  Now there are a lot more compliance hoops to jump
through.

In the end, a lot of it comes down to it “not being the unix way”.  I have
many of the same arguments and dislikes against systemd.  I have no issue
with the AIO installer, and in fact might use it on some older
centos/rhel5 hosts where getting modern ruby is hard.  My heartburn comes
from it being the only REAL way to install these packages starting with
version 4.  I’d much prefer you also support a more traditional
metapackage approach for the operating systems that support it.

Finally, the AIO package creation is a lot less repeatable.  If I need to
modify 3.7 locally, I modify it, change the spec to add a local component
and build a new RPM.  With this AIO, I need to grab the packaging repo and
spend some amount of time trying to figure out how to navigate it.

Hope that helps.

Jason


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

Re: [Puppet Users] Open Source 4.0 version identifier vs. very different rpm and dpkg package versions

[Jason Slagle]

On 6/22/15, 3:08 PM, "Vince Skahan"  wrote:

> On Thursday, June 18, 2015 at 4:18:37 PM UTC-7, Ken Bowley wrote:
>> This is better than what is currently being used, but I'm strongly in the AIO
>> idea to be stupid.  Split it into multiple packages and use proper
>> dependencies like every other sane packaging system has done for a long, long
>> time.
>> 
>> If all you do is bump the version of facter, then only have me download and
>> install the meta package that depends on the new facter, and the new facter
>> package, not everything.
>> 
>> 
> 
> Agree.   Thought I'd chime in (late) as the original poster.
> 
> Versioning starting with 4.x is a good start, but I still think your AIO
> approach is wrong.
> 
> Have collector rpms that 'require' the pieces of the puzzle and package
> hiera/etc. in individually bundled standalone packages.  If you do that:
> * you can keep versioning facter to 2.x.y if you want
> * you can keep versioning puppetserver any way you want
> * and just version the collection (bundle, pick a term) with the 4.x.x
> identifier you want to publicize as release-4.x.x
> To update the client, 'yum update puppet' and have it update the sub-pieces it
> needs (hiera/mco/etc.)
> 
> 
> 
> To update the server, 'yum update puppetserver' and have it do the server
> piece.
> 
> 
> 
> Lastly, if it's me, I would not bundle the agent/client stuff 'in' the
> puppetserver package.  I would 'require' the client-stuff to be co-installed
> with the server stuff using the packaging mechanisms the os providers already
> give you.
> 
> 
> 
> (in other words, release 'empty' rpms that require x and y and z - works great
> if you don't cause dependency hell by getting too fancy)


FWIW, +1 from me too.  It seems like a lot of places that do packaging like
this end up doing it this way.

If I¹m only doing a security update to facter, I shouldn¹t have to replace a
gigantic bundle with whatever else it pulls In.  I can see you release
management people hating this later, as well as security teams.

I suspect this confusion will hinder deployment ­ the AIO packaging is
certainly in the cons category for us.

Jason


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/D1ADE086.6002A%25raistlin%40tacorp.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Custom Fact used in exec command

[Jason Slagle]

On 4/23/14, 8:10 PM, "Aaron Shegrud"  wrote:


>I created a fact, loaded it into the my modules/[module]/lib/facter/
>directory
>it synchronized across all my users.
>I can see the fact in puppet-dashboard for all of my
>users:mac_airport_iden1
>but I cannot seem to use it in a command.
>
>I'm trying to run this command:
>
>exec {'killwifi':
>   command => '/usr/sbin/networksetup -setairportpower
>${mac_airport_id} off',
>   }
>
>but am getting an error on each run:
>Could not match ${mac_airport_id}
>
>
>

You need double quotes ­ single quotes don¹t interpret variables.

See http://docs.puppetlabs.com/learning/manifests.html

Jason


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CF7DD74C.4FA8%25raistlin%40tacorp.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet agent - two calls to server / request?

[Jason Slagle]

On 02/05/2014 11:54 AM, JonY wrote:

I set up a simple ENC this morning that just logs every agent request to
a file. What I've noticed is that every agent is logging two requests
per run. Each request is about ~10 seconds apart.

Is this normal? Are my agents not setup correctly?


This is normal as far as I know.

I suspect it has to do with either plugins or environment.

Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52F26D6C.2070802%40tacorp.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] "the Foreman" in Pro Puppet, 2nd edition

[Jason Slagle]

Maybe try the foreman mailing list?

Thanks,

Jason

On 01/06/2014 04:02 PM, Stuart Cracraft wrote:

Chapter 7 explains after installing Foreman that to start the installer:

  ruby /usr/share/foreman-installer/generate_answers.rb

is necessary.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52CB1AB6.8030306%40tacorp.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] The Future - ENCs vs Hiera?

[Jason Slagle]

On 01/04/2014 01:15 PM, Jose Luis Ledesma wrote:

I'm in the process of setting up puppet in my company and I don't like at all 
the idea of having some thousand of files for describe the nodes. And, despite 
the well known limitations, I like a lot the idea of having an enc like ldap.


So use this or a derivative:

https://github.com/hunner/hiera-ldap

I think the point is what was previously mentioned - everything you can 
do with the ENC you can do with hiera (I think environments may be the 
one exception).  You just need to write a hiera backend instead of an enc.


I actually suspect it'd be trivial to write a hiera backend that could 
just consume enc data.  It'd be a fairly limited backend since it'd 
really only work with certname, but it could be done.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52C857B8.5060704%40tacorp.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Provider must have features 'manages_symlinks' to set 'ensure' to 'link' shouldn't happen on Linux?

[Jason Slagle]

On 12/31/2013 04:16 AM, Steph Gosling wrote:

Isn't it!

Applying that resource fails in the same way: as requested here's the
output though debugging doesn't seem to add anything, which is a bit odd.

[root@nodename steph]# puppet apply --debug --verbose -e 'file {
"/tmp/test": ensure => link, target =>
"/tmp/test-target" }'
Info: Loading facts in /var/lib/puppet/lib/facter/hostname.rb
Info: Loading facts in /var/lib/puppet/lib/facter/memory.rb
Info: Loading facts in /var/lib/puppet/lib/facter/enumerate_xen_disks.rb
Error: Parameter ensure failed on File[/tmp/test]: Provider must have
features 'manages_symlinks' to set 'ensure' to 'link' at line 2
Wrapped exception:
Provider must have features 'manages_symlinks' to set 'ensure' to 'link'
[root@nodename steph]#

Running that on one of the functioning nodes and I get reams of
debugging output as I'd expect so it looks like there's something
curious with the environment, I just don't know what.


Out of curiosity, do you have both a package and the gem installed? 
I've seen this behavior when the package got updated, but the gem was 
still an older version.  Also make sure you bounce the master if the 
package got upgraded.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52C2C7A5.1050803%40tacorp.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] get a *structured* version of the puppet agent output

[Jason Slagle]

Hi Stuart,

Puppet Labs has a large professional service department that you might 
want to engage with these very specific requests.  I'm sure they can 
give you a hand with whatever you need done.


Jason

On 12/18/2013 12:55 PM, Stuart Cracraft wrote:

What we are looking for is a Ruby program which takes the contents of

   /var/lib/puppet/reports/*/*.yaml

and reports in detail on everything changed or proposed for change if in
noop mode
(file permissions, modes, user creates, etc.)

Stuart



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/52B1E2AB.7060909%40tacorp.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] A note on upcoming module metadata improvements

[Jason Slagle]

On 10/16/2013 12:07 PM, Ryan Coleman wrote:


  - operating_system : OSes your module supports stated like the
$operatingsystem Facter values Ubuntu or RedHat
- This new metadata will be used on forge.puppetlabs.com
 on module pages, search results and will
be available over its (soon to be released) REST API.



Ok, I'll bite :)

How does this plan to deal with all of the RedHat flavors?  If the 
module author doesn't list out RedHat, CentOS, OEL, Scientific, etc, 
will it work?


Might osfamily be better here? (With the caveat that Fedora should 
probably be it's own osfamily and not redhat).


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppetlabs-ntp template discussion

[Jason Slagle]

On 07/10/2013 06:33 PM, Jason Slagle wrote:

If you use hiera and puppet 3, specifying servers is as easy as putting
ntp::servers in hiera.


Bah!

And the reply to gets me again - this was a quick note just to him - 
hence no trimming and the top post.  Sorry about that.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] puppetlabs-ntp template discussion

[Jason Slagle]

If you use hiera and puppet 3, specifying servers is as easy as putting 
ntp::servers in hiera.


Jason

On 07/10/2013 04:52 PM, Dan White wrote:

OK.  Here are some wish-list items:

Using ntp by cron rather than as a daemon
An easy way to specify your own, internal time servers without tearing
up the class.
In the Red Hat template (since that's what I work on) : There is no
resource to ensure the driftfile exists or has the proper permissions on
it or on its directory.
And a comment: Is all the commentary necessary in the template ?

As I get time, I will be happy to make some contributions to the module
on my first two points -- I can do Red Had / CentOS / Fedora, but
someone else will need to assist on the other distros.

“Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)


*From: *"Ashley Penney" 
*To: *puppet-users@googlegroups.com
*Sent: *Wednesday, July 10, 2013 1:57:32 PM
*Subject: *[Puppet Users] puppetlabs-ntp template discussion

If you've ever refused to use the ntp module as it lacks something you
need, now is the time to shout out!

--
You received this message because you are subscribed to the Google
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.




--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Workflows and preventing accidental code promotion.

[Jason Slagle]

On 06/24/2013 04:59 AM, Gav wrote:

We have quite a large team spread across the globe making multiple
changes to Puppet manifests each day. This in itself can be a little
tricky to keep track of, but we also have multiple environments - ENG,
DEV, etc where we promote our changes to before they reach PROD.
Attached to each of those environments are the respective ENG, DEV, etc
servers. Some changes are can be quite major so they need to stay in a
particular period of time to allow other teams to test before they are
migrated up to the next environment.

All workflows that I have seen so far appear to be quite linear and
checkout a individual revision for any given environment, test, rinse
and repeat until production. I have read the dynamic environments blog
post 
several times trying to make it work for us, but I don't feel it does.
We wanted to cherry-pick individual changesets from one environment into
the next, ensuring you are not accidently promoting anyone elses changes.

I guess I am asking how you achieve a simple workflow and prevent
accidental promotion of someone elses code, whilst maintaining several
environments?


Howdy!

This seems more like a version control problem than a puppet issue - the 
same problem exists for developers testing stuff.


Have you looked at git-flow?  Basically it promotes a series of branch 
types to do various things.  You could have a handful of "release" 
branches that are what get pushed to the various machines.  Then you 
control what gets there by what you merge.  This prevents having to 
cherry-pick individual commits out of a given branch - just don't merge 
before you want it to go to the test machine.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Support for transactions

[Jason Slagle]

On 05/07/2013 09:13 AM, Denmat wrote:

Hi,

No, puppet is not transactionable. There is also no simple way to do it
in puppet and running noop first is no guarantee that the run will succeed.

Version control may help you out to 'roll back' but it would be messy
depending on changes. Traditional methods of snapshoting disk or
backup/restore can be wrapped around it (never done that myself).

Rspec testing can help you out a bit in testing as of course so can
other pre deployment testing.

If the client doesn't like 'always roll forward' then puppet might not
float their boat.



Couldn't he just make the downstream packages depend on package he is 
gating with?


You could even use a collector to add that package as a before to all 
other packages.  However, this will not handle any dependencies that yum 
for instance may bring in - you'd have to model those independently.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] How to manually create Puppet CA and client certificates using openssl?

[Jason Slagle]

Howdy!

I might suggest starting here:

http://projects.puppetlabs.com/projects/1/wiki/certificates_and_security


It talks a little about setting up a seperate CA - this is pretty 
commonly done for HA environments.


As far as pre-generating the client certs without Puppet, I'd have a 
look at ssl/host.rb in the source tree to see how it does it.  It has 
all the logic puppet certificate --generate uses (It seems to call 
generate_certificate_request), and then the logic --sign uses which 
calls ca.sign.  If you look through that code I'm sure you can figure 
out the right options to pass openssl to do it.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Installing fog -0.7.2 for CloudProvisioner

[Jason Slagle]

On 01/30/2013 03:11 PM, PuppetUser wrote:

Hi,

I am trying to install fog which is required for cloud provisioner.
 > gem install fog -v 0.7.2
I am getting the following error

Building native extensions.  This could take a while...


ERROR:  Error installing fog:
 ERROR: Failed to build gem native extension.

 /usr/bin/ruby extconf.rb
creating Makefile

make
/usr/lib/ruby/site_ruby/1.8/rubygems/ext/builder.rb:31:in `exec': No
such file or directory - make (Errno::ENOENT)

^^^

That's the issue right there.

It looks as if you don't have make installed on the machine.

You'll also need gcc and likely a bunch of -devel packages.

Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Re: Modules, yum repo's & best practices

[Jason Slagle]

On 12/31/2012 03:18 PM, Matthew Barr wrote:

Sorry to reply to myself.. but option #1 doesn't work.   (It works for
resources, but not classes. Silly me.)


So:  should forge modules use repo's explicitly?  or is there already a
  standard design pattern that implements a parameter  for repos?

else… I guess I'll end up writing one :)


What I've done is to let the baseurl for the repo optional be passed 
into the class as a parameter - that fixes it from my perspective.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Question on modeling multiple services sharing configuration

[Jason Slagle]

On 12/16/2012 01:09 AM, Roman Shaposhnik wrote:

Hi!

I would appreciate any advice on the best practices
on how to model a collection of services that each
has its own configuration file, but also share a common
one.

Now, the trouble is, that the common configuration file
is not *really* just a place for the common configuration
to reside, but also may have sections dedicated to holding
properties of a particular service (just like /etc/puppet/puppet.conf
has [main] [agent] and [master] sections).

Thus, in reality, the configuration properties are
per service and whether they need to go into a common
configuration file or a service-specific one is NOT cleanly
partitioned and is pretty awkward to remember. Which
means I really don't want to expose the common config
explicitly to the end user.

Instead, I'd like to expose the natural hierarchy of:

class service1($foo, $bar, $baz) {
}
.
class serviceN($qoo, $zoo) {
}

but the question then becomes -- how can I model a
common configuration file behind user's back so that
$foo, $bar and $qoo end up there.

At first I was thinking that I could utilize a singleton
non-parameterized class and include it multiple
times in all of the serviceX class definitions, but it
seems I can't pass any values into it.

I suppose I can still do that and create a skeleton
of the common config in that singleton class
that would later be manipulated either by augeas or
concat patterns, but this seems to be pretty heavyweight.

What would you, guys, recommend?


This is a pattern I feel augeas is awesome at.  I just did a similar 
thing for puppet.conf on my end.


Make the common configuration file virtual.  Give it a default "dummy" 
configuration file with replace = false (I do this because creating a 
file with augeas seems a bit shaky to me).


Then have each of the other services realize the common configuration 
file and use augeas to add their own specific configuration elements.


If the file is an inifile style, creating a lens is pretty trivial - you 
can see the puppet file lens (Which is in 
/usr/share/augeas/lenses/dist/puppet.aug on ubuntu) for an example.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] passenger used in puppet 3.0?

[Jason Slagle]

On 11/28/2012 09:53 AM, DJames wrote:

current dev system is using passenger, but production (babystage) is
using 3.0 version, and we have 1800+ servers (prod) that will be clients
is passenger the way to go still?



I was previously using passenger and just recently switched to using 
nginx/unicorn.  I like the setup a lot better - I can't really quantify 
why other than the architecture of the way it does it seems better to 
me, and getting passenger working was a pain under RHEL6.


General instructions here:

http://projects.puppetlabs.com/projects/1/wiki/using_unicorn

Some notes:

1) I ended up symlinking /etc/puppet to ~puppet/.puppet to fix the issue 
where puppet master not running as root will not look in the right place 
for it's config.


2) I couldn't find unicorn packages for RHEL - I ended up using gem2rpm 
and tweaking it to build.


3) I used supervisord instead of god because I'm more familiar with it. 
 Again you'll likely need to build packages for it - I just updated the 
spec here: https://github.com/easel/supervisor-rpm  There's a good 
puppet module to manage supervisord here: 
https://github.com/plathrop/puppet-module-supervisor


Thanks,

Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Technical Reviewers Needed

[Jason Slagle]

Gah :)  I hate it when lists set the reply to to the list.

Sorry,

Jason

On 11/26/2012 04:32 PM, Jason Slagle wrote:

That sounds interesting!  I'm game if you still need some.

Jason

On 11/26/2012 07:32 AM, joan...@packtpub.com wrote:

I am searching for a number of technical reviewers for a Puppet
Beginner's Guide that is currently in production. You need to have
good technical knowledge, and be able to spare a few hours every
couple of weeks to review the chapters. Please get in touch if you're
interested!





--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Technical Reviewers Needed

[Jason Slagle]

That sounds interesting!  I'm game if you still need some.

Jason

On 11/26/2012 07:32 AM, joan...@packtpub.com wrote:

I am searching for a number of technical reviewers for a Puppet
Beginner's Guide that is currently in production. You need to have
good technical knowledge, and be able to spare a few hours every
couple of weeks to review the chapters. Please get in touch if you're
interested!



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Uber Frustration with Puppet.

[Jason Slagle]

Doug,

I'm not terribly familiar with gluster, but that thing in your hand 
certainly looks square and you're trying to fit it in that round hole.


It looks to me like you've created an arbitrary service-centric data 
model, and are then attempting to smash on the tool (puppet) to make it 
work, and becoming frustrated with it.  I liken this to me designing 
some data structure with pointers, then venting that BASIC can't handle 
it [1].


As has been pointed out on several occasions on this list recently, most 
of us seem to structure our data in a host-centric model, not a service 
centric model.  This would flatten out the below structure quite a bit.  
It also would likely lead to duplication of data, which is what I 
suspect you're trying to avoid.  If you're keen on writing a python 
script, you could most likely write one to consume the below YAML file 
and spit out a node-centric YAML that could more easily be used by the 
puppet DSL.


Something like this maybe (No attempt has been made to make this validate)?

gluster_master_volumes: [gfsvol01]
gluster_bricks:
/var/bricks/gfsvol01-0:
device: /dev/bcvg/disk1
/var/bricks/gfsvol01-1:
device: /dev/bcvg/disk2

Then you should be able to use hiera_hash and creates_resources on 
gluster_bricks.


Another option would be to write a custom type to handle the gluster 
components.  Since types are written in Ruby, you should be able to use 
the data in a more native way, which would make looping over the hashes 
or arrays much easier.


If you need this to work as is, I suggest contacting Puppet for 
professional services - those guys over there are really awesome, and 
I'm sure they can whip something up that can consume the below data 
structure and do what you want with it.


Jason

[1] Ok, I'm sure one of you will point out some basic implementation 
with pointers


On 08/30/2012 01:50 AM, Douglas Garstang wrote:

Boy, am I frustrated. I'm about ready to throw puppet out the window
here. I'm trying to configure glusterfs, and you know, it kinda made
sense to separate the data from the manifests, so I went ahead and put
this into a YAML file, which hiera loads...

glusterfs_volumes:
   gfsvol01:
 volume_name: gfsvol01
 master_node: gfs01.us1.xxx.com # Make sure only one node
runs the gluster commands.
 nodes:
   - name: gfs01.us1.xxx.com
 bricks:
   - device: /dev/bcvg/disk1
 brick_name: /var/bricks/gfsvol01-0
   - device: /dev/bcvg/disk2
 brick_name: /var/bricks/gfsvol01-1
   - name: gfs02.us1.xxx.com
 bricks:
   - device: /dev/bcvg/disk3
 brick_name: /var/bricks/gfsvol01-0
   - device: /dev/bcvg/disk4
 brick_name: /var/bricks/gfsvol01-1

For the last couple of days I have been dealing with the inadequacies
of puppet in dealing with working with this kind of data structure.
You can't easily iterate through it, and every time you do, you have
to write a new definition that takes an array. The whole thing ends up
turning into a giant complicated mess.

I tried writing some custom functions in ruby that do things like,
return a list of nodes for a volume, or return a list of bricks for a
node, but it really irks me that I have to keep writing ruby scripts
for this (since ruby makes my eyes bleed).

So... what are my options here? Aren't we supposed to strive for
separating the manifest from the data? I could probably get away with
a few definitions that take a set of parameters. However, when the
time comes to say, add a new node to the cluster, we have to modify
the manifest. At one point, I had this working so that all you had to
do was add a node to the yaml file, make ZERO changes to the manifest
file, and after running puppet, it would add the node to the cluster.

It may make my life easier if I flatten the yaml file, but then I'm
changing the data to suit the limitations of the DSL.

At this point, I'm very close to simply sticking with the yaml file,
have puppet push that out to the clients, write some python scripts to
do all the magic (reading the yaml file), and have puppet run those
scripts with Exec {}.

Is proper array/hash iteration ever going to be added to puppet?

Doug.



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Managing puppet code

[Jason Slagle]

Below - didn't mean to toppost last time.

On 08/16/2012 10:46 AM, Dan White wrote:

May I politely disagree ?

I feel that using subversion branches for the different environments 
is defeating the fact that Puppet separates the environments thru the 
use of the environment setting.


Does that make any sense to you all ?

“Sometimes I think the surest sign that intelligent life exists 
elsewhere in the universe is that none of it has tried to contact us.”

Bill Waterson (Calvin & Hobbes)


*From: *"Jason Slagle" 
*To: *puppet-users@googlegroups.com
*Sent: *Thursday, August 16, 2012 9:28:29 AM
*Subject: *Re: [Puppet Users] Managing puppet code

Although it doesn't seem to do svn yet (You could extend it), I'm fairly
certain you could accomplish this with librarian-puppet.

It's on github.

Your Puppetfile would be in your main repo which could have
dev/stage/prod branches.



I suppose it depends on your use case.  Some people use environments for 
testing puppet, some people run seperate puppetmasters etc to do so.


Having attempted to manage this with git submodules and environments in 
the past, it's a real pain to make sure things happen the way you want 
them to.  Throw subversion into the mix and this is a real issue.


Manually promoting code from the "dev" enivronment directory to the 
"production" directory is a non-starter for most people, so at best 
you're going to see people check out seperate branches for each 
environment, which is still a branch model.  I still believe you could 
manage this with librarian-puppet - just do a puppetfile in each of the 
enviornment dirs.


Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Managing puppet code

[Jason Slagle]

Although it doesn't seem to do svn yet (You could extend it), I'm fairly 
certain you could accomplish this with librarian-puppet.


It's on github.

Your Puppetfile would be in your main repo which could have 
dev/stage/prod branches.


Jason

On 08/16/2012 07:22 AM, Benjamin Priestman wrote:
I'm piloting a puppet deployment that may grow to a fair size (~100 
nodes, at least two distinct sites, dev/stage/prod environments). I'm 
struggling a bit with settling on a strategy and processes for 
managing and deploying puppet code.


As seems to be generally accepted best practice and as required by the 
fact that there will be multiple teams likely to contribute modules 
for their applications, I'm managing the code for each 
internally-developed module in separate repositories - some SVN and 
some git-based, depending on the working practices of the different 
teams. I also want to make sure we have a way of pushing different 
modules through the different environments at their own pace 
(application a's module might be ready to move into production while 
application b's module should remain in UAT).


My issues are around how to pull all these modules together, and how 
to move them through dev/stage/prod environments in sane a reasonably 
simple way. There are a number whitepapers and descriptions of process 
around which mainly seem to rely on having a single git repo with 
different branches representing the different environments. I've got a 
kind of process working which links together different internal 
modules, as well as the git-hub sources of modules that have been 
published to the forge, making use of azimux's externals project 
(https://github.com/azimux/externals). This works quite nicely for 
constructing an unstable trunk/master and could be used to push 
monolithic tags through uat and prod. My current system for deploying 
individual tags, though, relies on creating a library of tagged 
modules and a forest of symlinks under $environment/modules. It works, 
but it is so complex it confuses me, let alone anyone else.


Using forge-style modules seems to be the way to go, but these will 
need management, too.


Does anyone have any suggestions?
--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/puppet-users/-/rVjji3SQhC8J.

To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Extending Puppet using Rubygems

[Jason Slagle]

On 06/25/2012 09:25 AM, Kelsey Hightower wrote:


John you make a really good point. Rubygems support would be totally 
optional. One of my hopes is that once people are able to use rubygems 
for things like parser functions and report processors we start seeing 
more OS packages built from those gems.





More useful might be a good and easy way to create OS packages to do 
plugins like this.


That would solve some amount of the chicken and egg problem you see 
bootstrapping puppet clients that need certain plugins.


I suspect this change will allow that since it will suck plugin stuff 
from a system location, so we don't have to go trying to create packages 
to throw stuff in $libdir?


Thanks!

Jason

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Re: Generating dhcp/pxe configuration from puppet

[Jason Slagle]

Christian,

I believe that The Foreman is basically something that solves this issue?

http://theforeman.org/

It can act as a ENC, as well as supporting provisioning.

Might be worth a look

On 04/20/2012 10:15 AM, Luke Bigum wrote:
Ahh, I see, I was running under the assumption that you already had 
Puppet Agents checking in.


How do you imagine this would work perfectly for you? Would you write 
node definitions in nodes.pp, then a Puppet Agent would do the 
DHCP/PXE on a specific server?


If so it sounds like you have nodes.pp as your "source of truth" for 
all your servers, and you want to feed DHCP and PXE with all your node 
information as a whole. That's pretty difficult to solve in Puppet 
because no node knows about another node, defined or otherwise (unless 
you somehow advertise it's there with exported resources).


Maybe you could write something that transferred your nodes.pp file to 
your DHCP server, then Puppet runs scripts to parse nodes.pp into the 
right DNS/DHCP config. It would probably be faster to write this 
(Perl), but I consider it a bit hacky - for every new server you're 
putting information into Puppet manifests only to pull it back out again.


If you've got the time I'd suggest you pull your source of truth out 
of Puppet and into another source like an external node classifier 
(some people use LDAP) or an external data source like Hiera. It would 
be a bit more work but might be easier to work with in the long run, 
as then you have a simpler problem to solve when you want to add your 
nodes into Software X in a few months.


Hope that helps,

-Luke

On 20/04/12 14:57, Christian Requena wrote:

Hi,

I set the whole thing up and got not the expected results. The thing
is, that:

"It’s important to mention here that you will only get exported
resources from hosts whose configurations have been compiled. If hostB
exports a resource but hostB has never connected to the server, then
no host will get that exported resource."

That means that the nodes must be already installed in order to use
the information.  I need this information mainly from the nodes that
are not existant yet. I want to boot them using PXE and run the whole
installation procedure afterwards.

I want to describe the nodes in a nodes.pp and from there setup DHCP
and PXE for them.

Any other hints?



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Increment variable each time a definition is called.

[Jason Slagle]

On Tue, 27 Sep 2011, Douglas Garstang wrote:


I hope that's not the only way. What I'm trying to do here isn't that
unusual. I have an several instances of an application running, each
with different port numbers. The definition sets the values for the
instance, but rather than listing the port numbers, which can cause
copy and paste errors, I wanted to have the port numbers auto
incremented from a base value.


Call me crazy, but I'm not sure I see the "common use case" here.  Puppet 
does not process a manifest top down (Well at least not in a way that you 
expect).


At best I would expect these port numbers to change at every addition.  At 
worst, I can see them changing every run.  I presume you're going to use 
these numbers elsewhere to configure some front end.  I'm not sure you'd 
want it reloading your apache, etc all the time as the port numbers bounce 
around.


If you REALLY wanted to do something like this, I might suggest you 
create a type, and define the namevar in such a way as to ensure you 
cannot have overlap.


Jason

--
Jason Slagle - RHCE5, VCP4
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
 X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] bug: --verbose on v2.6.6 doesn't always report changes. known and fixed in 2.7?

[Jason Slagle]

Are you running passenger?  I believe there is/was a known issue with this and 
passenger.

Jason

Sent from my iPad

On Sep 23, 2011, at 21:29, Jo Rhett  wrote:

> I want to check in and see if this is a known issue before I open a bug.  I'm 
> seeing a particular issue where after a manifest change, the first run with 
> the newly compiled catalog will not report the changes made to the system.
> 
> For example, 
> 1. I edited a manifest to change the ntp servers.  
> 2. I run "puppet agent --test" (which includes verbose) and it reports the 
> new catalog timestamp, but shows no changes 
> 
> info: Caching catalog for changes.for.me
> info: Applying configuration version '1316827173'
> notice: Finished catalog run in 248.13 seconds
> 
> 3. I confirm that the ntp.conf was in fact changed as per the new catalog
> 4. Reverse the ntp.conf edit by hand
> 5. Re-run "puppet agent --verbose" and it shows the changes being made
> 
> info: Caching catalog for changes.for.me
> info: Applying configuration version '1316827173'
> --- /etc/ntp.conf 2011-09-21 05:27:43.0 +
> +++ /tmp/puppet-file.8965.0   2011-09-23 06:08:12.0 +
> @@ -43,7 +43,11 @@
>  
>  # Specify the key identifier to use with the ntpq utility.
>  #controlkey 8
> +# Managed by Class['ntp']
> -server 10.50.0.2
> +server 10.50.0.1
> 
> info: FileBucket adding {md5}965a1ecdd47c86415ea2d0e52c632d99
> info: /File[ntp.conf]: Filebucketed /etc/ntp.conf to puppet with sum 
> 965a1ecdd47c86415ea2d0e52c632d99
> notice: /File[ntp.conf]/content: content changed 
> '{md5}965a1ecdd47c86415ea2d0e52c632d99' to 
> '{md5}883cdb9b8c44718eaadf1d3cea6cff96'
> info: /File[ntp.conf]: Scheduling refresh of Service[ntpd]
> info: /File[ntp.conf]: Scheduling refresh of Service[ntpd]
> notice: /Stage[main]/Ntp/Service[ntpd]: Triggered 'refresh' from 2 events
> info: Creating state file /var/lib/puppet/state/state.yaml
> notice: Finished catalog run in 249.33 seconds
> 
> In case you missed it, the same actions were taken by puppet client in steps 
> 2 and 5, but it only outputs the changes to the terminal session in step 5.  
> The catalog has not changed in between these steps.
> 
> This is persistently repeatable on CentOS 5.6 using the EPEL 2.6.6 puppet 
> RPMs.  Does anyone know if this problem has already been fixed or not, or 
> should I report it as a new bug?
> 
> -- 
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source and other 
> randomness
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Users group in NW Ohio or hell even Detroit/Ohio area

[Jason Slagle]

Anyone else out there using puppet that would be interesting in forming a 
users group if one doesn't already exist?


Jason

--
Jason Slagle - RHCE5, VCP4
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
 X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Puppet Community Updates

[Jason Slagle]

Does the fee cover av?

If they have a board/mic's then doing video/audio session recording becomes 
trivial.

Jason
Sent via Blackberry

-Original Message-
From: Andrew Shafer 

Date: Sat, 2 May 2009 15:31:34 
To: 
Subject: [Puppet Users] Re: Puppet Community Updates


The proposal I have from City Club right now is 20-30K for 100 people,
depending on what the food options are. (Food is the major expense.) I
thought it would be nice to have at least one nice big dinner together.

That also includes AV and WiFi.

The proposed menu is not terribly vegetarian friendly either, so I'll
probably have at least another iteration with them on different menus to see
what they can do if we go minimalistic on food and just hit the town. Might
be able to bring it down quite a bit, but these places make most the money
on the food, so we'll see.

I also want to work up a T-Shirt.

City Club Pros:
Location is Awesome

Cons:
Price might be a bit high

The City Club isn't a lock yet. I'd love to see people propose other
options.

I don't want to make any money on this and intend to be as transparent as
possible, I just want to get as many Puppet people together to share what
they do now and brainstorm about what they would like to be able to do. On
that note, anyone who is interested in presenting something let me know.
(planning to have a mix of presentations, workshops and open
spaces/unconference style discussions.)

Sponsors will essentially lower the price to attend. (For anyone out of town
the price of the camp will be eclipsed by travel and lodging.)

We can trade sponsors a logo/link/write up on the PuppetCamp website and a
logo on the T-shirt, and I'm open to ideas.

Another thing that would be awesome is if someone in the area has a hook up
to help us record some of the sessions.



On Sat, May 2, 2009 at 2:06 PM, Michael Halligan wrote:

> Andrew,
> What's the total cost for Puppet Camp in SF going to be? How much would it
> cost for BitPusher to sponsor it?
>
> Michael
>
> On May 2, 2009, at 1:03 PM, Andrew Shafer wrote:
>
>
> There is so much Puppet happening I have a hard time keeping track of
> everything...
>
> The Next Version
> 0.25 is close to a release candidate (probably would have been released
> last week if Luke wasn't running off to keynote a conference in Germany)
> The preliminary testing show significant performance improvements, but
> we'll have an extra long hardening period until 0.25 is the stable branch.
> 0.25 has a lot of internal reworking and we're really excited about what it
> enables. Hopefully it won't be too long until we can show you what that
> means.
>
> Puppet Camp
> I have a first estimate from the City Club in SF. I think it is a bit high,
> but they claim they can be flexible and it is a nice facility so I'm going
> to keep talking to them. I was hoping to keep the price in the $100-200
> range. The City Club probably puts us closer to $250 with continental
> breakfast and lunch for 2 days and a social dinner. I'm still open to other
> ideas or venues, but all the details probably need to be set in the next 6-8
> weeks. All you Bay Area people speak up...
>
> The Puppet Training in Belgium is filling up.
> The highest traffic on the registration site is from Spain, then Belgium,
> United States and Switzerland... interesting to see watch the demographics.
> http://reductivelabs.com/training/
>
> Puppet Jobs
> We've posted our first 'job' for a Sales Director. We have enough of a
> sales overhead that we want to be able to hand some of it off to focus on
> the Puppet platform. I'm sure most of you are allergic to 'Sales Guy', but
> if you happen to know of someone you trust and think they have the
> background to do a good job, send them our way. I will also post
> descriptions for developers, implementation consultants and support in the
> next few weeks. We'll take resumes for those positions now as well.
> http://reductivelabs.com/jobs/
>
> Feel free to pile on this thread and share anything you want to add. I'm
> thinking of putting up a community calendar for different Puppet talks,
> groups, conferences, etc. Would anyone use that?
>
>
>
>
>
>
>
> >
>




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Licensing and Copyright

[Jason Slagle]

On Tue, 7 Apr 2009, Burkholder, Peter wrote:

>> That's not how the model tends to work though.  Usually the
>> paid community gets the product first with the community
>> version lagging behind by a release.
>
> Huh?  Not in Red Hat's model:
>
> Fedora -> RHEL
> JOPR -> JON
> Spacewalk -> Satellite.
>
> The community version leads, not lags.

Different operating model than the ones I'm thinking of.  Things like 
zmanda as pointed out where the commercial version will get features or 
other items not yet present in the community edition.

Groundwork monitor seems to follow a similiar model.

It's more appropriate to new features, but thats where your bugs tend to 
come from.

And you're not exactly right.

Spacewalk was just born from satellite.  The open source version lagged by 
years.

Similiar story with GFS, directory server, etc.  The features went in the 
commercial product first.  Only later were they opened up.  If you 
consider them as addons to redhat, it makes the story similiar there.

The "Core" would lag, but the add ons bolted on would lead.  Those addons 
will be the things with bugs.

Luke has expressed a disinterest in this model though so it's largely 
irrelevant.



-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Licensing and Copyright

[Jason Slagle]

On Tue, 7 Apr 2009, Bryan Kearney wrote:

> Kyle Cordes wrote:
>>
>> There is dangerous territory nearby: Paying customers have a higher
>> expectation of a smooth out-of-box-experience, than open source users;
>> to make this happen it is necessary to debug vigorously. However, open
>> source users tend to chafe at the thought of a "community" version
>> intentionally left buggy while a "pay" version is fixed. I think the
>> only clean way out of this is a lot of debugging.
>>
>> Related to this, I can tell you from personal experience in commercial
>> software: support costs can be an enormously drain. The most effective
>> way to keep them down is with relentless quality improvement: kill bugs,
>> make features more comprehensible, document, make failure modes gentle,
>> make errors clear, etc.
>>
> But this is the value of a community. Too often the focus is on the
> developers. But users are even more valuable. If RL were to release a
> full featured community version, and then a supported version based on
> that.. the community is doing the hardening. This does not mean that the
> community version is bad.. just new. The proof would be that bugs get
> fixed in both.

That's not how the model tends to work though.  Usually the paid community 
gets the product first with the community version lagging behind by a 
release.

Jason


-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Licensing and Copyright

[Jason Slagle]

On Mon, 6 Apr 2009, Luke Kanies wrote:

>> I feel option number 2 will further limit the number of people
>> willing to
>> contribute code.  Especially if you plan to sell it commercially
>> later.
>> For instance, at my employer here I could contribute some code (and
>> as I
>> bone up on Ruby I may even attempt to, even if it's only some types
>> and
>> stuff at first).  However, it gets a lot stickier contributing back
>> if the
>> I'm contributing code that you may be selling.  Conflict and all.
>
> Can you elaborate on what you think the problems will be?
>
> I don't see how a conflict could develop.

Sure..

While $employer doesn't necessarily mind me contributing code to open 
source projects (As well as making donations which is something I'll 
certainly look at once I finish my rollout), it becomes a lot more harry 
if I'm working on code on $company's dime that your selling directly as a 
commercial product.

You almost are forced to make a pretty hard split like some of the other 
projects where you have seperate sites and everything for the "community 
edition" and the commercial one.

It can be done - I think mysql for instance does it fairly successfully. 
It's just considerably trickier from a contribution standpoint.

>> I must admit I'm a fan of the Apache license or a BSD license of some
>> sort.  It gives you the right to sell it while also remaining open.
>> It
>> also means that I don't have to have a copyright laywer on staff to
>> modify
>> your code and use it locally :)
>
> Well, you wouldn't need a copyright lawyer if you bought a license
> from us.  I think that's part of the reason for supporting dual
> licensing - if this is something that concerns your company, then you
> can solve it by paying a bit.  If you stay all open source, no problems.
>
> I'm not saying this is what I would do, but that it is the natural
> consequence of choosing a GPL-like license.

The AGPL is really scary with it's section 13.

It's be even scarier to me if I was a company doing hosting and trying to 
use your product, because it's a REALLY slipper scope when you deal with 
things like modules.

LGPL is a little better.  However, I think AGPL on a project like this 
that is very "programming" based is really a huge problem.

Jason


-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Licensing and Copyright

[Jason Slagle]

On Mon, 6 Apr 2009, Luke Kanies wrote:

> 1) Leave them like they are.  No copyright assignment, no real
> copyright maintenance, GPL2 or later.  This means that every
> contributor ever must give permission for things like license changes,
> we can't easily protect against license infringement 
> (http://www.gnu.org/licenses/why-assign.html
> ), no one can ever dual license, and essentially no commercial
> software can ever be produced that integrates with Puppet.
>
> 2) Stick to a viral/reciprocal license (probably AGPLv3) but require
> Sun-style copyright contribution (which provides the project a non-
> exclusive license to the copyright).  This provides a single
> organization with a license for all copyright, and allows that license
> holder (Reductive Labs) to protect against license infringement,
> provide patent indemnity (which I've already been asked about by
> others but cannot currently offer), relicense Puppet (and produce
> commercial software that integrates with that relicensed product),
> and probably more.
>
> 3) Switch to a non-reciprocal license (e.g., Apache) and don't require
> copyright coassignment.  This allows anyone to do anything with the
> code, so there's no real concern about license infringement and anyone
> can make commercial add-ons.  This is both good and bad, though, in
> that even those with no commitment to Puppet's community could build
> commercial products on it, which I think is not so great.

I think a lot of it depends on your goals.

Clearly long term #1 does not work.  It provides a big mess for you and 
puts in you a boat of only ever really being able to sell support.

I feel option number 2 will further limit the number of people willing to 
contribute code.  Especially if you plan to sell it commercially later. 
For instance, at my employer here I could contribute some code (and as I 
bone up on Ruby I may even attempt to, even if it's only some types and 
stuff at first).  However, it gets a lot stickier contributing back if the 
I'm contributing code that you may be selling.  Conflict and all.

I must admit I'm a fan of the Apache license or a BSD license of some 
sort.  It gives you the right to sell it while also remaining open.  It 
also means that I don't have to have a copyright laywer on staff to modify 
your code and use it locally :)

Jason

-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Alias for package list

[Jason Slagle]

On Mon, 16 Mar 2009, Felix Schäfer wrote:

> Haven't tried it, so take this with a grain of salt, but I'd wager you
> end with Package[["some", "software", "to", "install"]], which I don't
> think puppet can parse.

Would tags potentially give you what you needed?  Can you install them by 
tag?

Jason


-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Community: How to deal with attempts at sabotage

[Jason Slagle]

On Wed, 4 Mar 2009, Ben Beuchler wrote:

> It may be rude, but as long as they're not being threatening or
> interfering with the communication flow, it seems it would be silly to
> ban them.  To do so would seem to be saying that either:
>
> 1) the community members are too stupid to make their own decisions
> and must be protected from the dangerous teachings of the dissidents,
> or
> 2) the other community is, in fact, superior and you need to block
> communications in order to retain your own community.
>
> We're grown ups.  If someone is bugging us out-of-band, we can tell
> them to go away, block their email, or decide to accompany them to
> their fabulous World of Wonder and Excitement.
>
> Out of curiosity, which other group is trying to snipe people away?  Chef?

At the risk of naming names, I would guess it's chef amd fujin in 
particular he's talking about.

I'll say, that as someone who has been new at this and has had trouble, 
noone attempted to steer me towards them.  I actually had to specifically 
msg him and ask him what it was he was speaking of to get it out of him.

And after all that, and complaining in channel and on list that puppet was 
driving me crazy because it's anti-programmy, I stuck with it and didn't 
go to chef.

As you said, we're all grown ups.  I looked at the availability of 
examples and the userbase and decided even with it's shortcomings (and 
you're blind to think there aren't any), puppet was the way for me right 
now.

Anyone who it doesn't work for will eventually find chef anyways.  There 
is a class of people it clearly works for.  To me Ruby is a language I 
don't want to learn enough of to utilize Chef to it's fullest, but that I 
may be willing to learn enough to work around some of the puppet quirks 
that bother me.

Just my 2c.

Jason

-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Re: Banging my head on wall (hosts)

[Jason Slagle]

Don't get me wrong - I am using DNS.  I have 3 entries I want in each host 
file.  The primary production DB server (I don't want to run caching DNS 
everywhere, and I connect to it a lot.  It's also a failsafe if there are 
DNS issues) - the management box with puppet, and localhost.

Jason

-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .


On Fri, 27 Feb 2009, Trevor Vaughan wrote:

>
> Just out of curiosity, why aren't you using DNS?
>
> If you were, you could easily map your DNS to a hosts file for speed
> and synchronize it regularly.
>
> Alternatively, you could use a custom function on the server to make
> it all work for you.
>
> Trevor
>
> On Fri, Feb 27, 2009 at 17:13, Jason Slagle  wrote:
>>
>> Ok, so I figured I'd move this here since IRC isn't the place for it.
>>
>> Ok, so I have my 40ish servers.  Of those, 36 or so of them have hosts
>> entries that need to look like this:
>>
>> 127.0.0.1   localhost
>> 172.x.x.x   dbprod1.xxx.com dbprod1
>> 172.x.x.x   mgmt01.xxx.com mgmt01 puppet certmaster
>> 172.x.x.x   mybox.xxx.com mybox
>>
>> Where mybox is the name of the box.
>>
>> The others have a few additional entries.
>>
>> So, I made a class that creates those hosts entries and I include it on my
>> host.
>>
>> Part of the class does this:
>>
>>   host { "${fqdn}":
>> ip => $ipaddress,
>> alias => $hostname,
>>   }
>>
>> Seems simple enough eh?
>>
>> The issue comes up with those few exception.  In particular on the mgmt01
>> box.  It blows up because it I end up redefining the host, which is a
>> nono.
>>
>> So - lightbulb goes off in head.  I'll add a case to the class that checks
>> if the fqdn is one of the ones I manually insert, and if so I'll skip it.
>>
>> Now to me, this is a bad solution because it puts node specific logic
>> inside a class - I think that from a architecture/reusable component/large
>> scale perspetive that stuff belongs at the node definition.  I guess I
>> could just not use my host class on my exception.
>>
>> So, my next attempt was this:
>>
>> node mgmt01.xxx.com {
>>   $extrahosts = ["puppet", "certmaster"]
>>   include hosts
>> }
>>
>> So, I thought this would work:
>>
>> if $extrahosts {
>>   $myhosts = [$hostname, $extrahosts]
>> } else {
>>   $myhost = $hostname
>> }
>>
>>   host { "${fqdn}":
>> ip => $ipaddress,
>> alias => $myhost,
>>   }
>>
>> Still have the case to handle the duplicate type, but this allow me to
>> specify the extra aliases and handles the rest of my cases.
>>
>> But, this doesn't work.
>>
>> It would seem that the above not working in SOME form really limits the
>> ability to write modules/classes that work in 90% of the cases and can be
>> overridden in the other 10%.  This simplifies configuration a lot.
>>
>> Am I just doing something wrong?  Am I crazy?  Am I thinking too much like
>> a programmer?  Do I suck?
>>
>> Just looking for thoughts?
>>
>> Jason
>>
>> --
>> Jason Slagle - RHCE
>> /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
>> \ /   ASCII Ribbon Campaign  .
>>  X  - NO HTML/RTF in e-mail  .
>> / \ - NO Word docs in e-mail .
>>
>>
>>>
>>
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---

[Puppet Users] Banging my head on wall (hosts)

[Jason Slagle]

Ok, so I figured I'd move this here since IRC isn't the place for it.

Ok, so I have my 40ish servers.  Of those, 36 or so of them have hosts 
entries that need to look like this:

127.0.0.1   localhost
172.x.x.x   dbprod1.xxx.com dbprod1
172.x.x.x   mgmt01.xxx.com mgmt01 puppet certmaster
172.x.x.x   mybox.xxx.com mybox

Where mybox is the name of the box.

The others have a few additional entries.

So, I made a class that creates those hosts entries and I include it on my 
host.

Part of the class does this:

   host { "${fqdn}":
 ip => $ipaddress,
 alias => $hostname,
   }

Seems simple enough eh?

The issue comes up with those few exception.  In particular on the mgmt01 
box.  It blows up because it I end up redefining the host, which is a 
nono.

So - lightbulb goes off in head.  I'll add a case to the class that checks 
if the fqdn is one of the ones I manually insert, and if so I'll skip it.

Now to me, this is a bad solution because it puts node specific logic 
inside a class - I think that from a architecture/reusable component/large 
scale perspetive that stuff belongs at the node definition.  I guess I 
could just not use my host class on my exception.

So, my next attempt was this:

node mgmt01.xxx.com {
   $extrahosts = ["puppet", "certmaster"]
   include hosts
}

So, I thought this would work:

if $extrahosts {
   $myhosts = [$hostname, $extrahosts]
} else {
   $myhost = $hostname
}

   host { "${fqdn}":
 ip => $ipaddress,
 alias => $myhost,
   }

Still have the case to handle the duplicate type, but this allow me to 
specify the extra aliases and handles the rest of my cases.

But, this doesn't work.

It would seem that the above not working in SOME form really limits the 
ability to write modules/classes that work in 90% of the cases and can be 
overridden in the other 10%.  This simplifies configuration a lot.

Am I just doing something wrong?  Am I crazy?  Am I thinking too much like 
a programmer?  Do I suck?

Just looking for thoughts?

Jason

-- 
Jason Slagle - RHCE
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ /   ASCII Ribbon Campaign  .
  X  - NO HTML/RTF in e-mail  .
/ \ - NO Word docs in e-mail .


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---