Description of problem: Puppet Broker deployment run for OpenShift Origin aborts with two errors Version-Release number of selected component (if applicable): - Host system: Fedora 22 - Puppet 4.1.0-1.fc22.noarch - Facter 2.4.1-1.fc22.x86_64 How reproducible: Following the Puppet deployment guide below: https://docs.openshift.org/origin-m4/oo_deployment_guide_puppet.html we do get the above errors when calling the following commands: Steps to Reproduce: 1. puppet module install openshift/openshift_origin 2. puppet apply --verbose configure_origin.pp 3. Actual results: (1) Error: Evaluation Error: Error while evaluating a Function Call, Failed to parse inline template: undefined local variable or method `fqdn' for #<Puppet::Parser::TemplateWrapper:0x0000000378ff98> at /etc/puppet/modules/openshift_origin/manifests/init.pp:902:43 on node oso-stack-brokerinstance-gmeirhgknvpn.xx.xxxxx.xxx (2) Error: Illegal expression. A Reserved Word 'type' is unacceptable as function name in a Function Call at "/etc/puppet/modules/lokkit/manifests/services.pp:55:8' Error: Use of reserved word: type, must be quoted if intended to be a String value at "/etc/puppet/modules/lokkit/manifests/services.pp:55:8' Expected results: 1.) error (1) does not occur and is avoided by using the correct Puppet syntax for variable replacements 2.) error (2) does not occur and is avoided by using non-reserved function names Additional info: The reason for the problems: (1) Puppet variable replacements for Puppet Facter variables like "fqdn" are done using the following syntax "${}" instead of "#{}". Please replace this in file "/etc/puppet/modules/openshift_origin/manifests/init.pp" (see "$msgserver_tls_cert" and "$msgserver_tls_key") (2) reserved word "type" in Puppet module "lokkit" in file "/etc/puppet/modules/lokkit/manifests/services.pp" should be replaced with a named that is not reserved
After having fixed the above listed Puppet syntax errors in the corresponding files: - /etc/puppet/modules/openshift_origin/manifests/init.pp - /etc/puppet/modules/lokkit/manifests/services.pp the deployment passed successfully.
After having fixed the above errors in our local file system Puppet manifests, the following errors occur when Puppet is trying to configure the DNS environment and dealing with Puppet "Lokkit" ports (1) Error: Evaluation Error: Error while evaluating a Resource Statement, Cannot alias File[named infrastructure key] to ["/var/named/openshift.xxxxx.xxx.key"] at /etc/puppet/modules/openshift_origin/manifests/nameserver.pp:114; resource ["File", "/var/named/openshift.xxxxx.xxx.key"] already declared at /etc/puppet/modules/openshift_origin/manifests/nameserver.pp:75 at /etc/puppet/modules/openshift_origin/manifests/nameserver.pp:114:5 on node kih1fe-oso-broker.xx.xxxxx.xxx (2) Error: Illegal expression. A Reserved Word 'type' is unacceptable as function name in a Function Call at "/etc/puppet/modules/lokkit/manifests/ports.pp:53:10' Error: Use of reserved word: type, must be quoted if intended to be a String value at "/etc/puppet/modules/lokkit/manifests/ports.pp:53:10' Error: Illegal expression. A Reserved Word 'type' is unacceptable as function name in a Function Call at "/etc/puppet/modules/lokkit/manifests/ports.pp:63:10' Error: Use of reserved word: type, must be quoted if intended to be a String value at "/etc/puppet/modules/lokkit/manifests/ports.pp:63:10' ROOT CAUSES: (1) duplicate Puppet file resources for "/var/named/dynamic/${openshift_origin::domain}.db" in "/etc/puppet/modules/openshift_origin/manifests/nameserver.pp": when the following OpenShift class variables: - domain - dns_infrastructure_zone have the same value! When identical domain names for these two settings should be avoided, this exception is acceptable. file { 'dynamic zone': path => "/var/named/dynamic/${openshift_origin::domain}.db" ... file { 'infrastructure zone contents': pathc => "/var/named/dynamic/${openshift_origin::dns_infrastructure_zone}.db" (2) reserved words "type" in Puppet module "lokkit" in file "/etc/puppet/modules/lokkit/manifests/ports.pp" should be replaced with "type3x()" to allow Puppet 4 Future Parser compatibility! IMPORTANT: THIS FIX WILL ALSO HELP FOR ALL "type()" FUNCTION ERRORS MENTIONED AT THE BEGINNING OF THIS BUG. DETAILS CAN BE FOUND HERE: https://tickets.puppetlabs.com/browse/MODULES-1473 https://github.com/puppetlabs/puppetlabs-stdlib/pull/382
On top, the Puppet deployment run does not take care of: - FEDORA specific package names like: - 'rubygem-rhc' (Fedora) instead of 'rhc' (RHEL, CentOS) Take a look in "/etc/puppet/modules/openshift_origin/manifests/client_tools.pp" where the 'rhc' package name is only valid for 'RedHat' and 'CentOS' platforms in the following Puppet package and file resources: package { 'rhc': ensure => present, require => Class['openshift_origin::install_method'] } file { '/etc/openshift/express.conf': content => inline_template("libre_server = '${openshift_origin::broker_fqdn}'"), owner => 'root' group => 'root' mode => '0644' require => Package['rhc'], } As the package manager has changed starting with Fedora 22 from 'yum' to 'dnf' it would be good to have an additional: - install_method like 'dnf' next to 'yum'. Currently, this is not implemented. It is not critical as yum commands are forwarded to dnf up to now. But for future release of FEDORA this might be an issue!
Created attachment 1071700 [details] Fixed "client_tools.pp" taking care of the Fedora-specific package name for 'rhc' Enclosed a fix suggestion for the "client_tools.pp" OpenShift Puppet manifest!
Holger - thank you for digging into this. However, regarding your fixes for Fedora: per the original roadmap announcement[1], Origin M4 (and this puppet module by extension) is not supported on Fedora. The article goes into the reasoning behind this decision. Normally we would still offer to accept non-breaking changes as pull requests. However, in this situation we don't want to commit to long-term support of changes for a platform that was not targeted by the code. Having said this, we will review and test the lokkit / openshift-origin puppet module setup against CentOS 6.7. If any of the problems that you describe manifest there, we will put together pull requests with the relevant changes from your proposals above. [1]: https://blog.openshift.com/openshift-origin-road-map-doubling-down-on-developer-enablement-with-centos/
Dear N. Harrison, thank you for the hint and your blog entry regarding the "new" OpenShift strategy (since 2014) changing from OS to application level accompanied by a more stable fundament with an underlying OS that changes less rapidly. Keeping that in mind, we will switch to: - CentOS 6.7 - RHEL 6 for a proper deployment of OpenShift M4. Not quite sure, whether this limitation of supported OSs for OpenShift is communicated prominent enough - either we did overlook it or it is really not visible enough ;-)
Following problems during the Puppet deployment process on the Fedora OS platform are mainly related to missing OpenShift-specific yum-repositories that are not created: - openshift-deps.repo - openshift-origin.repo - jenkins-repo.repo - etc. There, additional RPM packages like "activemq" are located that are used in: - "etc/puppet/modules/openshift_origin/manifests/msgserver.pp" - etc. As soon as switching to: - CentOS 6.6 - RHEL 6 the deployment problems have gone! So, please avoid using Fedora (details see strategy announcement of N. Harrison Ripps: https://blog.openshift.com/openshift-origin-road-map-doubling-down-on-developer-enablement-with-centos/)
I have submitted a PR to address this issue: https://github.com/openshift/origin-server/pull/6237
Commit pushed to master at https://github.com/openshift/origin-server https://github.com/openshift/origin-server/commit/c0e6dada8898e889594e26ca04ca0660ff908650 Bug 1260987 - Add a note to the M4 Puppet Guide indicating supported OSes
Updates have been merged and pushed to https://docs.openshift.org/origin-m4/oo_deployment_guide_puppet.html