Thanks, I see what you mean now, and have been able to reproduce it locally.
The problem is that foreman_api is a rubygem, and these are packaged
into directories unique per package, e.g.
/usr/lib/ruby/gems/1.8/gems/foreman_api-0.1.11. rubygems itself (the
library that loads gems) is loaded once inside the Puppet process and
caches the paths under /usr for the gems it can find. When the new
package is installed, this cache needs to be reloaded (Gem.clear_paths
in Ruby).
I think the only place I can fix this is in Puppet itself, since it does
the testing and reloading of the foreman_api library. I'll file a bug
and patch.
···
--
Dominic Cleal
Red Hat Engineering
On 06/03/14 16:46, Luke Chavers wrote:
Dominic,
That was a silly oversight on my part. EPEL is one of just a few things
that we do install prior to running puppet. When I changed boxes I made
a mistake when adding the rpm execution to the bootstrap script.
So, 500 errors and problems later, I’ve finally made it back to the
point of this whole thing:
http://pastebin.com/v3tSW3bP
I had to shave off the top to meet the pastebin 500k rule, so hopefully
I did not eliminate anything important.
Debug: Failed to load library 'foreman_api' for feature 'foreman_api'
Debug: Puppet::Type::Foreman_smartproxy::ProviderRest: feature
foreman_api is missing
Debug: Logstash::Output::Tcp[logio-primary]: The container
Class[xxx::Profile::App::Logio::Stage_log] will propagate my refresh
event
Debug: Class[xxx::Profile::App::Logio::Stage_log]: The container
Stage[main] will propagate my refresh event
Debug: Failed to load library 'foreman_api' for feature 'foreman_api'
Debug: Puppet::Type::Foreman_smartproxy::ProviderRest: feature
foreman_api is missing
Error: Could not find a suitable provider for foreman_smartproxy
This is from the very bottom of the log and is the first mention of
foreman_api failures. Everything else in our rather large configuration
executed perfectly, until we get to the very end.
Hopefully there is some hidden gem in there that tells you what is up,
because I’m entirely at a loss.
Thanks,
Luke
–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-users+unsubscribe@googlegroups.com
mailto:foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com
mailto:foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.
As I said, this isn't my year
Error:
/Stage[main]/xxx::Profile::Env::Common::Security/Resources[firewall]:
Failed to generate additional resources using 'generate': Cannot allocate
memory - fork(2)
Error: Could not prefetch package provider 'yum': Cannot allocate memory -
fork(2)
… even though the VM has 1GB of RAM is sitting below 50%.
Once more unto the breach, dear friends, once more;
fyi… this is due to no swap being enabled on this CentOS 6.5 base box.
I'll probably just change boxes, but here's a resource for adding swap on
Ubuntu
(https://www.digitalocean.com/community/articles/how-to-add-swap-on-ubuntu-12-04).
I did not care enough to find a redhat variant. Hopefully these will
work: http://nrel.github.io/vagrant-boxes/
Thanks,
Luke
Ok, really?
/usr/lib/ruby/1.8/pathname.rb:287: [BUG] Segmentation fault
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
This would be funny if it wasn't so sad…
Ah, that is unfortunate. I will continue to search for workarounds.
Thanks again for being so responsive, you're a life saver.
-Luke
Sorry to spam this thread, I'm just trying to make sure that anyone who
finds this thread through Google after having the same or a similar problem
also finds the solution(s).
I "think" I've resolved the errors that are not related to Foreman above.
I switched to the Puppet Labs CentOS 6.5 (nocm / without Puppet) vagrant
box:
Base box
$lBoxFile = "puppetlabs-centos-65-x64-virtualbox-nocm.box"
$lBoxUrl =
"http://puppet-vagrant-boxes.puppetlabs.com/centos-65-x64-virtualbox-nocm.box"
I had some troubles with their 6.4 edition plus our sysadmin has informed
me that we're 6.5 in production now. Anyway, the "nocm" is currently
important because, as Dominic pointed out, puppet-3.4.x has these
unexplained segmentation fault errors.
So, my bootstrap script installs Puppet 3.3.2 with:
Epel, especially for Foreman later
rpm -Uvh
http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Puppetlabs
rpm -ivh
http://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-7.noarch.rpm
Install 3.3.2
yum -t -y -e 0 install puppet-3.3.2
So far, so good…
The "suitable provider for foreman_smartproxy" error still occurs, but
we're getting closer here. I also ran into some puppet-foreman weirdness,
but I'll post it another thread and open a issues and pull requests as soon
as I'm able.
Thanks,
Luke
I found several related resources for this:
http://alcy.github.io/2012/11/21/handling-gem-dependencies-in-custom-puppet-providers/
… and …
https://projects.puppetlabs.com/issues/17747
https://projects.puppetlabs.com/issues/6907
https://projects.puppetlabs.com/issues/7316
https://projects.puppetlabs.com/issues/14822
I'll post them to the issues you created also.
Thanks,
Luke
···
On Thursday, March 6, 2014 1:41:00 PM UTC-6, Dominic Cleal wrote:
>
>
> https://tickets.puppetlabs.com/browse/PUP-1879
> https://github.com/puppetlabs/puppet/pull/2415
>
> --
> Dominic Cleal
> Red Hat Engineering
>
