Hi Juanje,Harrison and I think we know the reason for these failures. Its basically due to how the installer sets up the Ruby environment for itself.We are working on a fix for the issue. Thanks for testing out the install and bringing the failure to our attention.—KrOn Oct 28, 2013, at 7:38 AM, Krishna Raman <kraman gmail com> wrote:Hi Juanje, Harrison,Im trying to reproduce this on ec2 now to debug why this may be happening. Will keep you updated.—krOn Oct 28, 2013, at 6:18 AM, N. Harrison Ripps <hripps redhat com> wrote:
On Oct 28, 2013, at 4:46 , Juanje Ojeda Croissier <juanje ojeda gmail com> wrote:Hi Harrison, thanks for your answer :-)
On Mon, Oct 28, 2013 at 1:10 AM, N. Harrison Ripps <hripps redhat com> wrote:
So far I've tried with Fedora 18, Fedora 19, Centos 6.4.
I tried the Puppet method described at the blog, but it has some issues with links and versions. I fixed some but I couldn't make it work.
Any specific error information that you can provide for the straight puppet installation path would be great. That said, oo-install uses the latest puppet scripts and part of oo-install is to write a *.pp file that configures the openshift/openshift_origin puppet module.
Well, I got errors since the first line:
$ curl -s https://nodeload.github.com/openshift/puppet-openshift_origin/legacy.tar.gz/master | tar zxf - --strip 1 '**/test'
tar: Pattern matching characters used in file names
tar: Use --wildcards to enable pattern matching, or --no-wildcards to suppress this warning
tar: **/test: Not found in archive
tar: Exiting with failure status due to previous errors
Then it tries to get the Vagrant's box but it seems to be gone:
$ wget https://mirror.openshift.com/pub/vagrant/boxes/fedora-sphericalcow.box
--2013-10-28 08:13:41-- https://mirror.openshift.com/pub/vagrant/boxes/fedora-sphericalcow.box
Resolving mirror.openshift.com (mirror.openshift.com)... 18.104.22.168
Connecting to mirror.openshift.com (mirror.openshift.com)|22.214.171.124|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-10-28 08:13:42 ERROR 404: Not Found.
There is a fedora-19 box instead: https://mirror.openshift.com/pub/vagrant/boxes/fedora-19.box
I made some changes and I got this working, but i got more issues that I don't remember now.I've also tried with the oo-install gem (which isn't at rubygems and you have to buid yourself, despite what the doc says), but nothing.
I use the bundler as a way of bootstrapping the app in development, but I believe that in the long term, the curl-to-shell method will be the supported approach for delivery. That said, if you want to work from your own copy of the source, you can always:
1. clone [openshift-extras]
2. cd to [openshift-extras]/oo-install
3. bundle install
4. bundle exec bin/oo-install
Thanks for the tip, I'll try next test.
But probably it would be a good idea to change this at the README file, because it says to install with "gem install oo-install", which doesn't work.
This is a great point; I will correct that this morning. The README hasn't been touched since I started the curl => shell bootstrapping work.
[...]But Puppet finished without success.
That's a bummer. Let's figure out what happened there.I can provide you logs, but I guess it's better do it at the Github project, right?
Actually for log files, are you familiar with the Fedora pastebin? https://paste.fedoraproject.org/ - Just throw log files there and send the URL to the list.
Well, I used Vagrant for my testing and I was using the opscode-fedora-19 box. I got up the VM and then:
$ sudo su -
$ yum -y update
$ yum -y puppet bind httpd-tools unzip
$ sh <(curl -s http://oo-install.rhcloud.com/)
Here is the output:
Then I ran the curl again and I got less Puppet errors:
Okay. So oo-install appears to have correctly configured Puppet, but Puppet ran into some trouble.
Krishna, can you please have a look at these logs? Is there something the installer should be doing differently to configure the Puppet module?
One thing I discovered is that Fedora 19 (most o my tests were with that distro) has Ruby 2.0.0 and the script search for Ruby 1.8 or 1.9.2. And later for a fixed path /opt/rh/ruby193/ which I didn't have in any distro.
oo-install is "vendored everything", meaning that all of its gem requirements are packaged with it. (I took care -not- to use any gems that need to be natively compiled.) Because of the differences between Ruby 1.8.7 and Ruby 1.9.x, I vendored two sets of gems. The bootstrapper chooses which set to make available through the $GEM_PATH based on some very simple logic: "Ruby 1.8.7" or "Everything Else".
That's a long way of saying, if you are using the curl-to-shell method (or using bundler) with Ruby 2.0.0 and you are running into problems, please send me some log files. I may need to vendor in gems expressly for Ruby 2.0.0, but my own recent experience with oo-install on Ruby 2.0.0 led me to believe that I wouldn't need to.
Well, I'm not sure if that is the problem, but it's something I found with made me suspicious. And I remember that I tried something by hand (after the curl-to-shell had failed) that show me some errors expecting some ruby PATH I didn't have, but I don't remember now, sorry.
If I get some info in that matter again, I'll post it here.
That would be great. Because the curl => shell approach cannot assume that Bundler is available on the installer host, the bootstrap script does a lot of the same work that Bundler does. But when you run the installer straight from source, you need to do it through Bundler so that you get the same environment. I'll note that in the README as well.
Glad to have the feedback. I hope we can get you up and running!
I hope so :-)
Thanks again for your help!
users mailing list
users lists openshift redhat com