[katello-devel] bundler install issues

Mon Jan 7 13:41:38 UTC 2013

I'm happy to report that TravisCI and Jenkins are now back up and running (in 15 min or less).

To fix the bundle install issues, I had to lock rails at 3.0.10. If anyone gets any gem problems after pulling down the latest version of the code, please let me know so I can try to help you.

Thanks.

David

----- Original Message -----
> From: "David Davis" <daviddavis at redhat.com>
> To: "Lukas Zapletal" <lzap at redhat.com>
> Cc: katello-devel at redhat.com
> Sent: Thursday, January 3, 2013 12:59:07 PM
> Subject: Re: [katello-devel] bundler install issues
> 
> Lukas,
> 
> I agree. The Rails platform is decent/mediocre at a lot of thing but
> great at nothing--and bundler is a good example of this. Just as
> Twitter started using other languages/technologies for things, I
> imagine we'll start to move away from some of the things Rails
> provides.
> 
> In the meantime, I was able to get TravisCI passing for Ruby 1.8 by
> specifying gem requirements on some of the gems that did not have
> any:
> 
> https://travis-ci.org/daviddavis/katello/builds/3934991
> 
> However, I used https://apps.fedoraproject.org/packages/ to find gem
> versions and some of the gems I could not find at all like
> rest-client.
> 
> David
> 
> ----- Original Message -----
> > From: "Lukas Zapletal" <lzap at redhat.com>
> > To: katello-devel at redhat.com
> > Sent: Thursday, January 3, 2013 10:47:31 AM
> > Subject: Re: [katello-devel] bundler install issues
> > 
> > David,
> > 
> > with my bundler.d patch, we no longer use Bundler in the production
> > mode. So you can now go ahead and apply the best practices you
> > think
> > are
> > good fit for us. Because bundler.d ignores versions, it just
> > require
> > everything from system.
> > 
> > In other words - Gemfile and all bundle.d/ files are now free to
> > change
> > versions. But I would recommend to stick with the lowest possible
> > library versions. For now it is Fedora 17 and RHEL6 - so if you
> > want
> > to
> > provide versions, keep in mind that we need to be compatible with
> > that. Bumping versions too high would mean we'd need to rewrite
> > some
> > portions after failed tests on longer-term supported platforms.
> > 
> > And I still think Bundler sucks - the major purpose of this tool is
> > to
> > resolve dependencies. But it can't do this due too poor resolver
> > design
> > and every single user must take care and "lower searching space".
> > 
> > That's like a nice car without speedometer which immediately stops
> > the
> > engine once you reach 80 mph without any warning. Yes, you can
> > start
> > the
> > engine again, but you need to pay attention not to push too much.
> > 
> > And I am not saying dependency resolution is easy, I can imagine
> > how
> > challenging this task can be. But resolver code was not touched for
> > an
> > year now. Makes me smile if I imagine how many people are using
> > Bundler.
> > 
> > I like simple software that does simple things - right. Oh, where
> > did
> > I hear this? ;-)
> > 
> > LZ
> > 
> > On Thu, Jan 03, 2013 at 10:23:38AM -0500, David Davis wrote:
> > > So having worked with Rails for a number of years, I've never had
> > > even a quarter of the problems we've had on katello. Then again,
> > > we usually always checked in the Gemfile.lock into our projects
> > > so
> > > they we were using the same gem versions across each platform (we
> > > even used different platforms like OS X, RHEL, and Ubuntu). This
> > > helped a lot to ensure that we didn't have problems due to
> > > different gem versions. Also, it helped to lock down gem versions
> > > so that when new gemm releases came out, stuff didn't break.
> > > 
> > > Another thing we did was we didn't have wide open gem
> > > requirements
> > > like we do on katello. There's many gems in our Gemfile and
> > > bundler.d files that have no requirements AT ALL. All the bundler
> > > documentation I've seen recommends in the very least using tiddle
> > > wakka [1]. Looking at the debug output from bundle install, it's
> > > obvious this is what the hold up is.
> > > 
> > > I mean you have to figure with no gem requirements, there might
> > > be
> > > 10s of gem versions for each gem and each version with up to 10
> > > dependencies (these dependencies must in turn be resolved). Times
> > > that by the number of gems that we're using and ALSO the gem
> > > dependencies that each gem has and you're looking at thousands of
> > > dependencies that bundler has to manage.
> > > 
> > > I don't think bundler's dependency resolver sucks so much as I
> > > don't think that bundler was meant to be used in the way we're
> > > using it.
> > > 
> > > David
> > > 
> > > [1] http://twiddlewakka.com/
> > > 
> > > ----- Original Message -----
> > > > From: "Lukas Zapletal" <lzap at redhat.com>
> > > > To: katello-devel at redhat.com
> > > > Sent: Thursday, January 3, 2013 10:07:01 AM
> > > > Subject: Re: [katello-devel] bundler install issues
> > > > 
> > > > Bundler dependency resolver just sucks, there are many reports
> > > > on
> > > > that
> > > > topic. I have learned, that the only way to fix this
> > > > undeterministic
> > > > behavior is to lower down the searching space.
> > > > 
> > > > Provide exact versions to few dependencies and then it will be
> > > > able
> > > > to
> > > > resolve. Start with biggest (richest) deps like rails. This
> > > > will
> > > > usually
> > > > help. Once the lock file is created, you can revert the change.
> > > > 
> > > > Various bundler/ruby combinations misbehave. Another reason why
> > > > I
> > > > am
> > > > not
> > > > using bundler even for development much.
> > > > 
> > > > LZ
> > > > 
> > > > On Thu, Jan 03, 2013 at 09:07:26AM -0500, David Davis wrote:
> > > > > I accidentally deleted my Gemfile.lock while working on a
> > > > > task
> > > > > to
> > > > > remove them and I'm noticing that it's taking 30+ minutes to
> > > > > run
> > > > > bundle install again. Running 'DEBUG_RESOLVER=y bundle
> > > > > install'
> > > > > locally seems to indicate that it's stuck on resolving gem
> > > > > dependencies. In the bundler issue below, the bundler teams
> > > > > recommends using more restrictive gem versions in the Gemfile
> > > > > to
> > > > > get around this.
> > > > > 
> > > > > https://github.com/carlhuda/bundler/issues/2101
> > > > > 
> > > > > Should we maybe take a look at refactoring our Gemfile? I'm
> > > > > thinking it could save us some time running jobs in jenkins
> > > > > and
> > > > > TravisCI as well. I think it would be important to write
> > > > > requirements that fit what's in the repos (F16, F17, RHEL6)
> > > > > and
> > > > > katello-devel-all.rpm.
> > > > > 
> > > > > Thanks.
> > > > > 
> > > > > David
> > > > > 
> > > > > _______________________________________________
> > > > > katello-devel mailing list
> > > > > katello-devel at redhat.com
> > > > > https://www.redhat.com/mailman/listinfo/katello-devel
> > > > 
> > > > --
> > > > Later,
> > > > 
> > > >  Lukas "lzap" Zapletal
> > > >  #katello #systemengine
> > > > 
> > > > _______________________________________________
> > > > katello-devel mailing list
> > > > katello-devel at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/katello-devel
> > > > 
> > 
> > --
> > Later,
> > 
> >  Lukas "lzap" Zapletal
> >  #katello #systemengine
> > 
> > _______________________________________________
> > katello-devel mailing list
> > katello-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/katello-devel
> > 
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 