[katello-devel] moving to ruby 1.9.3

Hugh Brock hbrock at redhat.com
Thu Oct 18 20:33:13 UTC 2012


On Thu, Oct 18, 2012 at 04:39:44PM +0100, Cliff Perry wrote:
> On 10/18/2012 01:14 PM, Bryan Kearney wrote:
> >On 10/18/2012 05:34 AM, Dmitri Dolguikh wrote:
> >>On 18/10/12 09:22 AM, Ivan Nečas wrote:
> >>>On 10/17/2012 07:18 PM, Hugh Brock wrote:
> >>>>On Wed, Oct 17, 2012 at 05:19:09PM +0100, Dmitri Dolguikh wrote:
> >>>>>On 17/10/12 05:04 PM, Jason Rist wrote:
> >>>>>>On 10/17/2012 09:37 AM, Dmitri Dolguikh wrote:
> >>>>>>>As part of port to Ruby 1.9.3, I'd suggest moving away from custom
> >>>>>>>ruby
> >>>>>>>repository for bundler-based installs, and switch to rubygems.org
> >>>>>>>repository instead. Folks still would rather use Fedora-provided
> >>>>>>>gems
> >>>>>>>can do so, since Fedora 17 versions of 'bundler' and 'gem' are
> >>>>>>>yum-aware. This would simplify dependency management during
> >>>>>>>development.
> >>>>>>>
> >>>>>>>
> >>>>>>>As the next step I'd like to propose to switch to rails 3.2 (the
> >>>>>>>version
> >>>>>>>of Rails that's going to be shipped with f18) in master (which is
> >>>>>>>what
> >>>>>>>Aeolus folks did).
> >>>Let's call it Fedora 18 support :)
> >>>>>>>
> >>>>>>>
> >>>>>>>-d
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>katello-devel mailing list
> >>>>>>>katello-devel at redhat.com
> >>>>>>>https://www.redhat.com/mailman/listinfo/katello-devel
> >>>>>>I think this is what we should have been doing. Can we not develop
> >>>>>>upstream in a more normal rails fashion and then deal with
> >>>>>>packaging and
> >>>>>>the like downstream? Or is that too much work?
> >>>>>>
> >>>>>I'm not sure why we aren't doing this atm. Considering that we have
> >>>>>a suite of integration tests that is being run *after* katello has
> >>>>>been packaged, it's safe to split development and packaging - we are
> >>>>>able to catch the issues.
> >>>Here are some reasons why we care about RPM packages from the beginning:
> >>>
> >>>1. Katello as a working thing by far isn't just a Rails app and
> >>>outside of the Ruby word gems mean nothing.
> >>>2. The installation process is part of the whole project. Using the
> >>>installation process that will be used in production from start means
> >>>catching the issues sooner than just before release
> >>>3. Creating an RPM forces you to thing about the license soon. It's
> >>>not pleasant to find out that your code is not shipable because of the
> >>>licensing issues
> >>>4. The code has to work on the target platform (which is Fedora an
> >>>RHEL for us), and (as Metallica sings) nothing else matters
> >>>5. Things like selinux need to be solved as well.
> >>>6. This approach is Continuous Delivery compliant: and now we are
> >>>having 2-months CR release cycle
> >>>
> >>>You can do whatever you want on the development machine. And I have
> >>>nothing against improvements that will make development on non-Fedora
> >>>based systems easier. But when you want to merge into the master, you
> >>>have to count on the fact that somebody will want to install it on
> >>>test or production machine.
> >>>
> >>>Unlike Aeolus, we don't try to get Katello into Fedora official repos
> >>>yet (though our client packages are already there). And getting the
> >>>packages to Fedora it the thing that makes the packaging harder and
> >>>slows down the process: waiting for 2 weeks till the library can be
> >>>used is just too much. Therefore we have our own Koji instance, where
> >>>the deps go in the first place, and then we can work on getting them
> >>>to Fedora later while development goes on.
> >>>
> >>>So what I'm saying is: it would be great if someone clones our repo,
> >>>runs bundle install and the server runs on every platform (though I
> >>>don't thing forcing the developer to run all the deps (like Pulp,
> >>>Candlepin, Katello-Cli) from source would make the Rails developer
> >>>happy. But giving up our nightly builds and all the good things that
> >>>go with it just for this reason is really huge step backward. And I
> >>>don't see a reason that this two things couldn't co-exist together.
> >>>
> >>>-- Ivan
> >>
> >>I think we need to standardize on whether replies go above or below the
> >>original comment :)
> >>
> 
> In the middle - don't standardize - cos people will then complain.
> We are all grown adults and can adapt to everyone's habits.
> 
> >>
> >>I don't think anybody participating in this thread suggests that
> >>packaging is not important. Nor is anyone talking about about abandoning
> >>nightly builds, etc.
> >>
> >>I'm suggesting that we remove development process dependency on build
> >>artifacts. Let's use rubygems.org in development (I know of several
> >>people who are doing this already; it's *very* useful to be able to add
> >>new dependencies in development quickly). Let's use system-provided gems
> >>in packaged Katello.
> >>
> >+1
> 
> Personal opinion.
> 
> I'll suggest, if you make a pull request for katello in github, that
> you have resolved gem packaging/build before submitting a patch/code
> that requires a new gem. In other words - hack away as you want, but
> once you want it formally in Katello - clean it up and make it
> easily consumable for all, wanting to install Katello from nightly
> rpm based yum repos. If a pull request requires a new(er) gem, then
> it should be rejected until that gem is packaged and available via
> rpm in one of the usual repos for katello.
> 
We did this for a while with Aeolus. Unfortunately it confuses the hell
out of ruby developers who don't know anything about RPM.

Imagine for a moment that you are a top-notch rails programmer. Unless
you already work at Red Hat, chances are you've never had to write an
RPM spec before.

Now let's say by some miracle you become interested in contributing to
upstream Katello, or Aeolus. You poke around, talk to people, figure out
that the feature you want isn't already in progress and that upstream
would like to have it. So you go off and write the thing. Along the way
you add your friend's handy gem that does XYZ.

When you submit your patch upstream, we say, oh, gee, sorry, we don't
take patches that add gem dependencies unless you also wrap them up in
this arcane packaging format that is redundant (for rubyists) and not
the least bit useful to you.

I don't think I need to describe what the typical reaction would be...

If we ever want any of these projects to fly on their own without 100%
support from Red Hat, we have to stop doing things that make them weird
to non-RH folks. Like even talking about RPM... or, god help us,
Fedora. 

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey



More information about the aeolus-devel mailing list