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

Dmitri Dolguikh dmitri at redhat.com
Thu Aug 2 12:16:33 UTC 2012


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).

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






More information about the katello-devel mailing list