[katello-devel] A couple of community-related questions

[Hugh Brock]

On Thu, Aug 02, 2012 at 01:16:33PM +0100, Dmitri Dolguikh wrote:
> On 02/08/12 12:57 PM, Lukas Zapletal wrote:
> >On Thu, Aug 02, 2012 at 10:37:32AM +0100, Dmitri Dolguikh wrote:
> >>Aeolus project has an extension for Bundler that allows for simple
> >>switching between bundler- and rpm-based application deployments. It
> >>relies on an environment variable to switch between the two
> >>behaviours. In rpm-mode the extension takes over dependency loading:
> >>it relaxes version restrictions for gems, and then loads the
> >>dependencies. See https://github.com/aeolus-incubator/bundler_ext
> >>for details and https://github.com/aeolusproject/conductor/blob/master/src/config/application.rb
> >>for example of real-world use.
> >>
> >There has been several approaches discussed this year on the fedora ruby
> >sig mailing list.
> >
> >Katello took the simplest approach - to delete Gemfile.lock every start,
> >bundler just creates new from existing (local) system gems.
> That's not a great approach. You just removed specific versions of
> gems for deployment. Not everybody deploys using rpms (I, for one,
> don't).

We had several motivations for going down the Bundler path and it
seems worthwhile explaining them -- and thanks for your interest, BTW!

First: While we recognize that our product will be delivered as RPMs,
we also recognize that the set of Real Ruby Developers who deliver
their projects as RPMs ~= {}. We are very, very focused on upstream
growth and involvement right now, and I am absolutely committed to
knocking down any barriers in the way of external contributors. Yum
and RPM and a Fedora dependency are, unfortunately, barriers. Rather
high ones, as it turns out.

Second: It has been really quite easy to patch Bundler to allow
developers to work in whatever way they want. Want to use system gems
installed as RPMs? mv Gemfile Gemfile.in and set the appropriate
environment variable. Want to use rvm + userspace gems? Do nothing --
it just works. There's really no inconvenience either way.

Third: I can't even begin to count the man-months we have expended on
packaging gems as RPMs, tracking down their dependencies and packaging
them, for no one's benefit but our own. *No one* uses the
fedora-packaged rubygems that we spend so much effort on except us. We
then have to redo most of that work to make things work on RHEL. It's
a total time-sink that our competitors simply do not have to deal
with. For this reason, I'm pushing our upstream to ignore RPM
packaging altogether and work "the ruby way." We'll package for RHEL
as part of gearing up for product releases, and hopefully the advent
of DSCs will make that a bit easier.

Anyway, this was the motivation behind the bundler patches. I hope
they turn out to be helpful for you guys!

Take care,
--Hugh

> 
> >
> >Foreman uses approach to run bundler install --local in the post RPM
> >transaction. It's quick and nice, but it does not work when you update
> >dependencies (then it actually breaks).
> >
> >Aeolus uses this, which I like the most at first sight. It basically
> >turns off bundler
> >
> >Ruby Fedora packagers (Vit Ondruch) are currently communicating with
> >bundler upstream to add some (non-default) option to force usage of
> >system gems. But upsteam seems to resist. I guess that aeolus-incubator
> >piece is result of this discussion.
> I don't have high hopes for this one - I tried having this
> conversation with Bundler folks, but I don't think they a lot of
> interest in supporting rpm- (or any other package-manager) based
> setups.
> 
> >I'd rather wait how Fedora packagers will solve this issues. They are
> >under heavy pressure from various Red Hat and Fedora Ruby teams. All
> >have the same issue with Bundler. It really seems the Aeolus approach is
> >the best IMHO.
> Since the outcome of Vit's negotiations is far from certain, and
> should things turn out favourably for us the solution would be
> similar to Aeolus (if not theirs altogether), I'd rather do it
> sooner than later - the amount of work is not that big.
> 
> >
> >So how about to re-raise this again in two months?
> >
> >Btw Bundler is Linux-unfriendly in terms of serious deployment. It's
> >a weird approach Rails community fallen in love with IMHO. Very "cool"
> >for initial development, but that's all.
> Bundler has it's uses. I happen to think it's perfect for
> development, especially if you are working on multiple applications
> - you can easily have per-application dependencies. Bundler is also
> great for traditional web-application deployments, as it guarantees
> that you will end up with exact dependencies you need.
> 
> Let's face it - rpms and bundler-based deployments are two very
> different use cases, and we *have to* support both.
> 
> -d
> PS> Perhaps we need to have a broader discussion about the idea of
> Katello community. How do we see it? What kind of developers we
> expect to attract? Users of which linux/unix distros do we expect to
> attract?
> 
> 
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel

-- 
== 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