[Puppet Users] Puppet introducing instability to Docker on Debian Jessie

[Tom Noonan]

I'm seeing a bug that appears to be a bad interaction between Puppet
and SystemD on Debian Jessie that causes my Docker daemon to go
unavailable.  I'm running both Docker and Puppet from upstream:

root@docker0:~# dpkg --list | grep 'lxc-docker\|puppet'
ii  facter 2.4.4-1puppetlabs1all  
Ruby module for collecting simple facts about a host operating system
ii  hiera  1.3.4-1puppetlabs1all  A 
simple pluggable Hierarchical Database.
ii  lxc-docker 1.6.2 amd64
Linux container runtime
ii  lxc-docker-1.6.2   1.6.2 amd64
Linux container runtime
ii  puppet 3.8.1-1puppetlabs1all  
Centralized configuration management - agent startup and compatibility scripts
ii  puppet-common  3.8.1-1puppetlabs1all  
Centralized configuration management
ii  puppetlabs-release 1.0-11   all 
 "Package to install Puppet Labs gpg key and apt repo"

For this test I've stripped my manifest down to the minimum: only a
service declaration for Docker on the node:

node "docker0.tjnii.com" {
  #Debug
  service { 'docker':
ensure => running,
enable => true,
  }
}

Docker is started by Puppet via SystemD without issue:

root@docker0:~# puppet agent --test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for docker0.tjnii.com
Info: Applying configuration version '1434419985'
Notice: /Stage[main]/Main/Node[docker0.tjnii.com]/Service[docker]/ensure:
ensure changed 'stopped' to 'running'Info: 
/Stage[main]/Main/Node[docker0.tjnii.com]/Service[docker]: Unscheduling refresh 
on Service[docker]
Notice: Finished catalog run in 0.88 seconds

root@docker0:~# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; disabled)
  Drop-In: /etc/systemd/system/docker.service.d
   service-overrides.conf
   Active: active (running) since Mon 2015-06-15 20:01:45 MDT; 32s ago
 Docs: http://docs.docker.com
 Main PID: 25160 (docker)
   CGroup: /system.slice/docker.service
   25160 /usr/bin/docker -d -H fd://



root@docker0:~# docker ps
CONTAINER IDIMAGE   COMMAND CREATED 
STATUS  PORTS   NAMES
root@docker0:~# ps awwfux | grep [d]ocker
root 25160  0.6  0.9 273044 14984 ?Ssl  20:01   0:00 
/usr/bin/docker -d -H fd://
root@docker0:~# ls /var/run/docker.sock -l
srw-rw 1 root docker 0 Jun 15 20:01 /var/run/docker.sock


After a few Puppet daemon runs (I haven't nailed it down to a fixed number, 
perhaps
a race?) Puppet will think Docker is down and try and restart it:

Jun 15 20:32:35 docker0 puppet-agent[1271]: 
(/Stage[main]/Main/Node[docker0.tjnii.com]/Service[docker]/ensure) ensure 
changed 'stopped' to 'running'
Jun 15 20:32:35 docker0 puppet-agent[1271]: Finished catalog run in 1.10 seconds

This will replace the socket with a new file:

root@docker0:~# ls /var/run/docker.sock -l
srw-rw 1 root docker 0 Jun 15 20:32 /var/run/docker.sock

However the Docker daemon is not restarted.  Note that the pid hasn't
changed from when it was initially started:

root@docker0:~# ps awwfux | grep [d]ocker
root 25160  0.4  1.1 557024 17008 ?Ssl  20:01 0:11 /usr/bin/docker 
-d -H fd://

So after Puppet tries to start the service it looks like the Docker daemon 
becomes
disconnected from its socket.  Puppet is exacerbating this, if I stop Puppet 
Docker
is stable.  I'm wondering if this has something to do with the docker.socket
SystemD service, but I don't know enough about SystemD to troubleshoot that.

This is the SystemD config from Docker:

root@docker0:~# systemctl cat docker.service
# /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=http://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
ExecStart=/usr/bin/docker -d -H fd://
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/docker.service.d/service-overrides.conf
[Service]
EnvironmentFile=-/etc/default/docker
root@docker0:~# systemctl cat docker.socket
# /lib/systemd/system/docker.socket
[Unit]
Description=Docker Socket for the API
PartOf=docker.service

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

I'm not sure if this is a Puppet bug, SystemD bug, or Docker bug.  has anyone 
else seen
behaviour like this with Puppet and SystemD?

--Tom Noonan II

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving e

Re: [Puppet Users] Puppet 4 API, questions about custom functions and "data binding" in modules

[Francois Lafont]

Hi,

Sorry Henrik for my late answer.

On 12/06/2015 01:54, Henrik Lindberg wrote:

> Cool, you are an early user, we expect to add more to this, and the road 
> may be a bit bumpy at the beginning :-)

Generally, I'm not a "early user" but currently I need to create a new
Puppet infra from scratch and it seemed to me more logical to choose
directly Puppet 4.

>> 1. About the "data binding" in a modules, if I understand well the
>> `./mymodule/lib/puppet/functions/mymodule/data.rb` function replaces
>> completely the "params" pattern, so that the "params" pattern is
>> completely useless in a module using the Puppet 4 API. Is is correct?
>>
> 
> It is an alternative to using the "params" pattern, yes. Now, since it 
> is possible to write the "mymodule::data" function in the puppet 
> language it should also be much easier and the code should look very 
> similar to the puppet logic for the "params" pattern.

Ok, I see but if the data() function is a function in the puppet language,
should I change the name of the file? Should I take
`./mymodule/lib/puppet/functions/mymodule/data.pp` (.pp extension) instead
of `./mymodule/lib/puppet/functions/mymodule/data.rb`? In this case, should
I modify the content of the file 
`./mymodule/lib/puppet/bindings/mymodule/default.rb`?

In fact, when I want to just manipulate data, I think I prefer the
Ruby language because the fact that variables are immutable in the Puppet
language causes me problems sometimes (just when I want to manipulate
data, to merge 2 hashes, make a look in a hash to retrieve a specific
value etc. etc).

> (One more related tip is to take a look at the deep case match feature 
> when writing logic that have many if/then/else and nested such expressions).
> 
>> 2. Always about the "data binding" in a modules, is it correct to say
>> that the `data.rb` function replaces too the default values in the
>> declaration of a class? For instance with:
>>
>> class mymodule (
>>$param1 = 'default1',
>>$param2 = 'default2',
>> ) {
>>...
>> }
>>
>> I can remove the default values in the class and put it in the `data.rb`
>> function. Is it correct?
>>
> Yes you can remove the defaults if you are sure you have values for them 
> in the data function - this because they will automatically get values.
> 
> A reason to keep them is for documentation purposes; they may help 
> increase the understanding of how to use the class.

Ok, I see.

>> 3. In a module, if I have 2 public classes foo.pp and bar.pp, is it
>> possible to have 2 different `data.rb` functions, one for foo.pp and one
>> for bar.pp? Or maybe I can have only one `data.rb` function which
>> provides simultaneously the default values for foo.pp *and* bar.pp?
>>
> 
> There is only one function that is called by the "data in modules" 
> framework. There is nothing stopping you from implementing it by calling 
> other functions and composing the result. Thus, modularizing the design.
> 
> Say something like:
> 
> function mymodule::data() {
>mymodule::data::classa() + mymodule::data::classb()
> }
> 
> function mymodule::data::classa() {
>$prefix = "mymodule::data::classa"
>{ "${prefix}::param1" => valuea1,
>  "${prefix}::param2" => valuea2,
> }
> }
> function mymodule::data::classb() {
>$prefix = "mymodule::data::classb"
>{ "${prefix}::param1" => valueb }
> }

Ok, I see.

>> 4. In a custom function with the Puppet 4 API, in the `dispatch` method,
>> is it possible to provide more complex types than 'Array' or 'String',
>> for instance is it possible to provide types like "an array of strings"
>> or "an non empty array of non empty string"?
>>
> Yes, types have parameters for things like that; min, max lenghts, 
> contain data types. There is a rich type system.
> (See the documentation, or my blog posts on the topic).
> 
> Array[String[1]] # array of non empty strings, array may be empty
> Array[String]# array of strings (possibly empty string), -"-
> Array[String[1], 1] # non empty array of non empty strings
> 
> Read more here: 
> http://puppet-on-the-edge.blogspot.se/2014/02/the-puppet-type-system-blog-posts.html

Ah ok. So I can use the same syntax that I can use in the parameters
of a puppet class declaration. That's cool and avoid some painful
checking in the code. Cool. :)

>> 5. In a custom function with the Puppet 4 API, is it possible to get the
>> value of a variable in a module or of a fact? With the Puppet 3 API,
>> it's possible with `lookupvar('xxx')` but it works no longer with the
>> Puppet 4 API.
>>
> 
> Access to the content of the calling scope is a bad idea for general 
> purpose code - it is far better to have pure functions (they process 
> what they are given as arguments and return a value).

Ok, I understand well the "function" paradigm but if it's just in order
to *read* a fact, for instance to just read the 'lsbdistcodename' fact
and put it in a variable, is it really a bad idea? Ok I can add a parameter
to my function `fct(a, b, lsbdi

[Puppet Users] Command Exceeded Timeout on Basic Shell Commands

[Franck]

We've been experiencing a lot of "Command exceeded timeouts" on basic shell 
commands using the "exec" type for tasks that should execute fairly fast: 

Jun 15 15:45:44 host1 puppet-agent[57648]: 
(/Stage[main]/Timezone::Utc/Exec[/bin/rm -f /etc/localtime && /bin/ln -s 
/usr/share/zoneinfo/UTC /etc/localtime]) Command exceeded timeout
Jun 10 21:15:24 host1 puppet-agent[57081]: 
(/Stage[main]/Open-vm-tools::Package/Exec[/usr/bin/vmware-uninstall-tools.pl]/onlyif)
 
Check "/usr/bin/test -f /usr/bin/vmware-uninstall-tools.pl" exceeded timeout
Jun 10 23:56:02 host1 puppet-agent[40286]: 
(/Stage[main]/Open-vm-tools::Package/Exec[/usr/bin/yum install -y 
open-vm-tools.x86_64]/unless) Check "/bin/rpm -q open-vm-tools" exceeded 
timeout

All these commands can be run locally to the host and return fairly 
quickly, but when puppet executes them they time out. Extending the timeout 
is an option but ridiculous since default is 300 seconds and none of these 
commands should take 5 minutes or more to return.  

Some of the things observed is that this only affects CentOS 6.x hosts as 
we also have Ubuntu 14.x hosts and they do not experience these problems. 
 Also, we've played around with different versions of the puppet agent 
along with different versions of Ruby and none of them had any effect as 
this condition persists regardless.  Also, this does not seem to affect all 
of our CentOS 6.x hosts but only certain ones -- randomly.  Running puppet 
agent in debug mode does not seem to uncover what's going on as it just 
hangs when it gets to the "exec".

It's very annoying and actually dangerous in some cases as the puppet agent 
will continue spawning multiple "applying configuration" processes which 
will cause hosts to swap memory as each takes up more and more memory and 
in some instances will hose them entirely.  
We've had to remove these manifests that cause these conditions in the 
interim but right now we have a lot of hosts we need to manage with puppet 
so we need to be able to use this.

Basic info on the hosts in question:

   - Puppet: 3.7.5
   - Ruby: 2.1.2
   - CentOS 6.6

Anyone have any ideas as to what could be causing this?

Thanks.
Franck

-- 
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/f2071040-32e1-4c9b-8656-5a33650c67ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Calling hiera functions from inside Ruby templates broken in Puppet 4.x?

[Henrik Lindberg]

On 2015-13-06 3:59, Henrik Lindberg wrote:

On 2015-04-06 24:37, Stephen Gelman wrote:

Henrik,

Thanks for the reply.  Now that it is established that this is a problem
is there a plan to re-add this functionality?  Should I submit a ticket
for it?



Here is the ticket that was logged for this. A solution is in the works.
https://tickets.puppetlabs.com/browse/PUP-4753



To close the loop:
There is now a fix for this that will be released in 3.8.2 and 4.2.0.

Scope gets a new method, so the original problematic template line can 
be written as:


GATEWAY=<%= scope().call_function('hiera',['gateway']) %>

The new scope.call_function can be used both with and without future 
parser in effect, it always takes arguments as specified by 4.x (i.e. no 
funny "undef is empty string"), and if needed it will convert to the 3.x 
calling convention if the target function is implemented as a 3.x function.


- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

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

[Puppet Users] Re: issue svn with r10k stderr: svn: URL 'http://xxxx/puppet/environment/development/branches' non-existent in that revision

[Anderson Mills]

It appears that you are using "environment" (without an s) in the value for 
your remote: key,

but your svn repository appears to use "environments" (with an s).

Hope that helps,
Anderson

On Friday, June 12, 2015 at 7:06:20 AM UTC-7, Spriya wrote:
>
> Hi,
>
> I am almost getting there implementing svn with r10k. I am stuck here. 
> Anyone can you help me in this. I am having this error:
>
> *Stderr:*
> *svn: URL 
> 'http:///svn/puppet/puppetlabs/puppet/environment/development/branches 
> ' 
> non-existent in that revision*
> *Exit code: 1*
>
> Here is my r10k.yaml
>
> cat r10k.yaml
> ---
> # This example configuration details the most commonly used configuration
> # options for the `r10k deploy` command.
> #
>
> # The 'cachedir' setting controls where cached content, such as mirrored 
> Git
> # repositories, are stored on the local machine. This location should be
> # persistent, as environments and modules may rely on these files in order 
> to
> # be updated.
> #
> # See 
> https://github.com/puppetlabs/r10k/blob/1.5.1/doc/git/cloning-and-mirroring.mkd
> # for more information on how r10k caches Git repositories.
> #
> # The default value is "~/.r10k"
> cachedir: '/var/cache/r10k'
>
> sources:
>
>   development:
> type:  svn
> remote: '
> http://xxx-xxx-xxx/svn/puppet/puppetlabs/puppet/environment/development'
> basedir: '/etc/puppetlabs/puppet/environments'
> username: ''
> password: ''
> prefix: false
>
>
> Here is my branches and trunk in my repository
>
> http:///svn/puppet/puppetlabs/puppet/environments/development
> ->branches
> -> trunk
>

-- 
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/8e68fd7a-fbce-48cc-a94c-fd4b39457a4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet 4: webserver configuration

[Sergey Arlashin]

Hi!

I'm trying to configure webserver via conf.d/webserver.conf  . 

The purpose is to add an extra web resource called 'secure-store' that can be 
used later in 'file' resource type.  

This is how webserver.conf  looks at the moment: 

webserver: {
  default: {
access-log-config = /etc/puppetlabs/puppetserver/request-logging.xml
client-auth = want
ssl-host = 0.0.0.0
ssl-port = 8140
default-server: true
  }

  secure-store: {
access-log-config = /etc/puppetlabs/puppetserver/request-logging.xml
ssl-host = 0.0.0.0
ssl-port = 8141
ssl-cert = /etc/puppetlabs/puppet/ssl/certs/p4server.site.pem
ssl-key = /etc/puppetlabs/puppet/ssl/private_keys/p4server.site.pem
ssl-ca-cert = /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem
client-auth = need
static-content: [{resource: "/etc/puppetlabs/code/secure_store/"
  path: "/secure-store"}]

  }
}

I can easily get files from there with curl :

# curl -k --key ./private_keys/p4agent.site.pem --cert ./certs/p4agent.site.pem 
 https://p4server:8141/secure-store/testtest.txt

But I cannot get anything using 'file' resource type in my manifests:

This is how it looks: 

  file { '/tmp/testfile.txt':
ensure  => present,
owner   => root,
group   => root,
mode=> '0700',
source => 'puppet://p4server.site:8141/secure-store/testtest.txt'
  }

I see the following error when I try to run it: 

Error: /Stage[main]/Testfile/File[/tmp/testfile.txt]: Could not evaluate: Could 
not retrieve information from environment production source(s) 
puppet://p4server.site:8141/secure-store/testtest.txt

And the following record in puppetserver-access.log:

 "GET 
/puppet/v3/file_metadata/secure-store/testtest.txt?environment=production&links=manage&checksum_type=md5&source_permissions=ignore
 HTTP/1.1" 0 0 p4agent.site 172.16.15.12 8141 1

Could anyone please tell if I'm doing anything completely wrong or I 
misunderstood the idea of webserver thing regarding new puppet server ?

Thanks in advance. 

--
Best regards,
Sergey Arlashin







-- 
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/BA40F1D1-EDDA-4EBE-B131-B49456929B3F%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Problem using hiera-eyaml

[Niranjan Putha]

Hi Levent,

I am getting  similar error as you where eyaml commands are working but not 
hiera-eyaml.  I was getting the below error before following your 
suggestion of installing gem by using /opt/puppet/bin/gem 

Error before :
notice: hiera(): Cannot load backend eyaml: no such file to load -- 
hiera/backend/eyaml_backend
Could not find data item foo in any Hiera data file and no default supplied 
at line 1 on node


After i re-installed hiera-eyaml using /opt/puppet/bin/gem i am getting the 
following error now
Error Now:
notice: hiera(): Cannot load backend eyaml: no such file to load -- 
hiera/filecache
Could not find data item foo in any Hiera data file and no default supplied 
at line 1

Any idea what this could be? Greatly Appreciate your help.

Thanks
Niranjan 

On Tuesday, July 15, 2014 at 5:29:05 AM UTC-4, Levent Tutar wrote:
>
> eyaml commands were working but not hiera-eyaml. 
> the following solved my problem. 
> default gem install uses the wrong gem environment. puppet uses a 
> different one.
> use /opt/puppet/bin/gem to install hiera-eyaml instead of default 
> /usr/local/bin/gem
>
> On Thursday, January 2, 2014 4:44:32 PM UTC+1, Kit Plummer wrote:
>>
>> Hey Werner.  
>>
>> I just added the 'read' permission to the global setting on the installed 
>> gems' directories after the 'gem install' command.  I had to do it for 
>> hiera-eyaml and the gems that were installed with it.
>>
>> Kit.
>> On Jan 2, 2014 8:39 AM, "Werner Bahlke"  wrote:
>>
>>> Hi Kit,
>>>
>>> I am glad you found the cause. Can you tell me a bit more how you 
>>> resolved it? I probably can figure it out eventually but any hints will be 
>>> greatly appreciated.
>>>
>>> Thanks,
>>>
>>> Werner
>>>
>>>
>>> On Mon, Dec 30, 2013 at 11:17 AM, Kit Plummer  
>>> wrote:
>>>
 Hey Werner.  I did resolve my issue.  It turned out to be a path issue, 
 with how the PE’s rubygems installs gems.  While the eyaml commands were 
 working, the directory for the hiera-eyaml (and it’s dependent gems) 
 didn’t 
 allow the pe-puppet user (global perms) to get to the lib .rb files in the 
 installed gems.

 It’s a bug and I need to remember to file it.

 Kit


 --
 From: wernerbahlke werner...@gmail.com
 Reply: puppet...@googlegroups.com puppet...@googlegroups.com
 Date: December 30, 2013 at 9:12:48 AM
 To: puppet...@googlegroups.com puppet...@googlegroups.com
 Subject:  [Puppet Users] Re: Problem using hiera-eyaml

 >
 > Hi Kit,
 >
 > Thanks for posting. No, I did not resolve it and have put it on the
 > back
 > burner. Quite possible that it is a Ruby / gems issue.
 >
 > Keep us posted if you resolve it before me.
 >
 > Werner
 >
 > On Saturday, December 21, 2013 11:13:46 AM UTC-5, Kit Plummer
 > wrote:
 > >
 > > Did you resolve this?
 > >
 > > I'm having a similar problem. But, I think it is because the eyaml
 > > backend isn't getting loaded :) :
 > >
 > > "Cannot load backend eyaml: cannot load such file --
 > > hiera/backend/eyaml_backend"
 > >
 > > I'm wondering if this is because the Ruby version/Gems that
 > are used by PE.
 > >
 > > On Friday, December 6, 2013 8:10:35 AM UTC-7, wernerbahlke
 > wrote:
 > >>
 > >> I am trying to use hiera-eyaml and have followed the README
 > instructions.
 > >>
 > >> eyaml seems to work, I can encrypt and decrypt files and passwords.
 > >>
 > >> I can also use hiera -c to get at an encrypted value like so:
 > >>
 > >> hiera -c /etc/puppetlabs/puppet/hiera.yaml rootpwd
 > >>
 > >> But when running this simple test module it fails with cannot
 > find the
 > >> data item rootpwd defined in hieradata/defaults.eyaml.
 > >>
 > >> class test {
 > >> $test = hiera('test')
 > >> $rootpwd = hiera('rootpwd')
 > >> notify { "Test: ${test}": }
 > >> }
 > >> If I just have the test variable defined in defaults.yaml it
 > works fine.
 > >> So it cannot find the defaults.eyaml file.
 > >>
 > >> Here is my hiera.yaml:
 > >> --
 > >>
 > >> :backends:
 > >>
 > >> - yaml
 > >> - eyaml
 > >> - :hierarchy:
 > >> - defaults
 > >> - "%{clientcert}"
 > >> - "%{environment}"
 > >> - global
 > >> - :yaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
 > >> - :eyaml: :datadir: /etc/puppetlabs/puppet/modules/hieradata
 > >> - :pkcs7_private_key:
 > >> /etc/puppetlabs/puppet/secure/keys/private_key.pkcs7.pem
 > >> - :pkcs7_public_key:
 > >> /etc/puppetlabs/puppet/secure/keys/public_key.pkcs7.pem
 > >>
 > >> And my defaults.eyaml file:
 > >> --
 > >>
 > >> rootpwd: >
 > >> 
 ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQAwDQYJKoZ

Re: [Puppet Users] A case for git (SVN vs Git)

[Paul Seward]

On 12 June 2015 at 19:14, Ramin K  wrote:

>
> Being somewhat in the middle of a similar conversation at $dayjob
> I believe it's a mistake to focus on the technology rather than the
> outcome. I would focus on workflow, integration, and tooling instead.
> Particularly the local branch per feature or ticket to review board to
> merge to release branch is flexible, powerful, and relatively easy to
> understand.
>

Having recently been through this (we used to use svn and have migrated to
git) - the workflow/tooling are definitely the thing to focus on when
describing it to management.

Feature branch based workflow, with code reviewed merge requests (which can
also be queued pending review board approval if that's how you roll) are an
easy sell to management - and a world of pain to manage in svn.

With git (and a supporting toolset like
github/bitbucket/gitlab/stash/whatever) that branch/merge based workflow is
super easy.

"You'll find yourself about 900x more agile with git or the like" -
> Binford2k
>

branching/merging in git is really the killer feature for me.  Compared to
svn, branch/merge is almost so easy it's fun!

Since moving from svn to git, our time-to-fix has gone down, changes are
easier to stage so are more predictable, and we're pushing around 3 times
as many changes through per week than we were able to before. Yet all those
changes are peer reviewed and discussed before they're merged to
production, in a level of detail which just wasn't possible before.

It's made us more productive at a higher level of quality - and why
wouldn't a decision maker want that?

Regarding the document linked to by the OP
https://github.com/logicminds/A-Case-For-Git.git - there are some claims in
there which stretch the truth a bit too far for my liking - eg all the
stuff about r10k not working with svn, or that you lock yourself out of
using 3rd party modules without a lot of effort.

I've never tried, but I can't see anything technologically that would stop
you from using svn for your local code control and still using r10k to
retrieve 3rd party modules via git - but the document reads like the sky
will fall in if I try.

When I'm presenting options to management, I generally need an unbiased
assessment of the problem space, a description of what I'm trying to
achieve, and a clear, unbiased assessment of how each of the options
meets/misses those criteria.

I would suggest starting by defining a desired workflow (eg, problem is
identified, development environment created, change made, change tested,
change queued for approval, fix merged to production) then evaluating how
svn and git meet those requirements in a fair unbiased manner.

Obviously git will still win in any scenario which involves
branching/merging - but at least you'll have gone about it in a structured
way, and that's hard to argue against.

-Paul
-- 
--
Paul Seward, University of Bristol
paul.sew...@bristol.ac.uk  +44 (0)117 39 41148GPG Key ID: E24DA8A2
GPG Fingerprint:7210 4E4A B5FC 7D9C 39F8  5C3C 6759 3937 E24D A8A2

-- 
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/CAKzNK-abQaersQN-OPcEnZWbCe-NFRKt0_PUFNHX5frV0EK25Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Can Puppet-Dashboard run on Passenger 5?

[Melvin Mah]

 

Has anyone encountered problem of running Puppet Dashboard on Ruby 
Passenger 5? If yes does it really work with that Passenger version?

   1. 
   
   I've already setup and configured the necessary files required to run 
   Puppet Dashboard via Passenger. Currently, the Apache test page is shown 
   instead of the dashboard menu. This will not appear if Puppet-Dashboard is 
   run in the lightweight Webrick server.
   2. 
   
   While scouring most of the installation samples and the manuals on how 
   to install and configure it for Centos 6. I've seen most of them were based 
   on Passenger 3 / 4. *I am currently using 5.0.10* as it is used in 
   conjunction with Puppet 3.8.1. One thing certain is that RailsAutoDetect is 
   deprecated in version 5 and that has been commented out.
   3. 
   
   Below my puppet-dashboard.conf file (the load module has been moved to 
   another file to avoid double-instantiation)
   4. 
   
   On the logs, the first error reported is that the path of 
   /usr/share/puppet-dashboard/public/reports/upload is not there, so I've 
   created those sub-folders to see if what would be the next error. 
   5. 
   
   The next error in the log file after that is now shown like: Attempt to 
   serve directory: /usr/share/puppet-dashboard/public/reports/upload/
   6. 
   
   External node and node terminus option has been commented out as not to 
   disrupt normal puppet run-interval activities during office hours.
   7. 
   
   PassengerHighPerformance onPassengerMaxPoolSize 6PassengerPoolIdleTime 
1500PassengerStatThrottleRate 120 
   Listen 3000
  ServerName mi-cloud-mgmt-config-01
  ServerAlias mi-cloud-mgmt-config-01.mimos.local
  RailsBaseURI /
  PassengerAppRoot /usr/share/puppet-dashboard/
  DocumentRoot /usr/share/puppet-dashboard/public/
   # UPDATE THIS TO YOUR FQDN
   Options None
   Order allow,deny
   allow from all
   ErrorLog /var/log/httpd/dashboard_error.logLogLevel debugCustomLog 
/var/log/httpd/dashboard_access.log combinedServerSignature Off
   
   

-- 
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/f9c77371-a14d-4137-acb3-3719e18bb708%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.