Yeah, seems sane - for reference this is the useful bit, at startup:
D, [2018-01-03T15:04:30.442526 ] DEBUG -- : 'puppet' settings: 'enabled': https, 'puppet_version': 4.1.3, 'use_provider': [:puppet_proxy_puppet_api]
D, [2018-01-03T15:04:30.444284 ] DEBUG -- : Providers ['puppet_proxy_puppet_api'] are going to be configured for 'puppet'
D, [2018-01-03T15:04:30.484301 ] DEBUG -- : 'puppet_proxy_puppet_api' settings: 'api_timeout': 30 (default), 'classes_retriever': apiv3, 'environments_retriever': apiv3, 'puppet_ssl_ca': /etc/puppetlabs/puppet/ssl/certs/ca.pem, 'puppet_ssl_cert': /etc/puppetlabs/puppet/ssl/certs/puppet.pem, 'puppet_ssl_key': /etc/puppetlabs/puppet/ssl/private_keys/puppet.pem, 'puppet_url': https://puppet:8140, 'puppet_version': 4.1.3, 'use_provider': [:puppet_proxy_puppet_api]
This tells us all the settings it was initialized with. It looks sane, but check the addresses, certs etc are right.
So, assuming clients are still finding the classes Foreman wants to delete (that is, the puppetserver still finds them and can compile catalogs) then the next question is why the proxy can’t see them. It’s an API call to the puppetserver, so it ought to work the same way as for the puppetserver itself. I may have to defer to @Dmitri_Dolguikh for help on this one… Dmitri, is there any difference in the parser for Puppet 4 vs Puppet 5?