Project

General

Profile

Actions
Copy link

Bug #19979

closed

Puppet Integration with non-puppetserver Puppet 4.x broken

Added by Anonymous almost 8 years ago. Updated almost 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Puppet
Target version:
-
Difficulty:
Triaged:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:
Foreman - 1.15.0
Red Hat JIRA:

Description

The current distinction which way to use for environment and class retrival is only made by the value of :puppet_version:. This breaks things when Puppet 4.x is used, but no puppetserver. When no PC1 repos are enabled, this is the default configuration on Debian/stretch and Debian/jessie with backports.

Actions
Copy link
 #1

Updated by Anonymous almost 8 years ago

I'm inclined to say this is by design. The alternative is to maintain a custom puppet parser, which is something we tried to avoid to begin with.

Actions
Copy link
 #2

Updated by Anonymous almost 8 years ago

Dmitry, what would be your preferred way of solving this? Easiest would be to introduce a parameter like force_legacy to load puppet directly again. However, For some reason setting puppet_version to 3.8.7 on such a setup still doesn't make the classes show up in the Foreman UI, although the proxy seems to work correctly now:

D, [2017-06-11T13:38:25.108292 ] DEBUG -- : Scanning stdlib classes in /etc/puppet/environments/production/modules/stdlib/manifests/init.pp
D, [2017-06-11T13:38:25.108556 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.112951 ] DEBUG -- : Scanning stdlib classes in /etc/puppet/environments/production/modules/stdlib/manifests/stages.pp
D, [2017-06-11T13:38:25.113154 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.116847 ] DEBUG -- : Scanning ntp classes in /etc/puppet/environments/production/modules/ntp/manifests/service.pp
D, [2017-06-11T13:38:25.117197 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.122742 ] DEBUG -- : Scanning ntp classes in /etc/puppet/environments/production/modules/ntp/manifests/config.pp
D, [2017-06-11T13:38:25.122941 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.126838 ] DEBUG -- : Scanning ntp classes in /etc/puppet/environments/production/modules/ntp/manifests/init.pp
D, [2017-06-11T13:38:25.127080 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.131901 ] DEBUG -- : Scanning ntp classes in /etc/puppet/environments/production/modules/ntp/manifests/install.pp
D, [2017-06-11T13:38:25.132180 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
D, [2017-06-11T13:38:25.138879 ] DEBUG -- : Scanning ntp classes in /etc/puppet/environments/production/modules/ntp/manifests/params.pp
D, [2017-06-11T13:38:25.139082 ] DEBUG -- : Initializing from Puppet config file: /etc/puppet/puppet.conf
I, [2017-06-11T13:38:25.143973 ]  INFO -- : 192.168.122.241 - - [11/Jun/2017 13:38:25] "GET /puppet/environments/production/classes HTTP/1.1" 200 2 0.2080
Actions
Copy link
 #3

Updated by Anonymous almost 8 years ago

My preferred approach would be for users to install the puppet server. Otherwise they are relying on our custom parser, which is never going to be as good as puppetlabs' one. Not to mention that I'd prefer not to maintain our custom parser -- puppet internals keep changing, and it would attention (if not huge amounts).

Actions
Copy link
 #4

Updated by Anonymous almost 8 years ago

  • Status changed from New to Rejected
  • Translation missing: en.field_release deleted (240)

nothing will be done here.

Actions
Copy link

Also available in: Atom PDF