[katello-devel] moving to ruby 1.9.3
Ivan Nečas
inecas at redhat.com
Thu Oct 18 14:56:07 UTC 2012
Just to put it on the right track: no development dependency will break
the nightly RPM builds. Neither the build nor the production RPMs are
dependent on the custom gems repo. So nobody's holding you form getting
rid of custom repo, keeping the information about the dependencies in
the Gemfile, maintaining a wiki page (or better a script because the
wiki will get more obsolete sooner than you finish writing it) to run
everything without RPMs at all etc. But if you add production
dependencies, you should care about it running in production from the
beginning, that's all I ask you for.
-- Ivan
On 10/18/2012 02:45 PM, David Davis wrote:
> +10
>
> David
>
> ----- Original Message -----
>> From: "Hugh Brock" <hbrock at redhat.com>
>> To: "Bryan Kearney" <bkearney at redhat.com>
>> Cc: katello-devel at redhat.com
>> Sent: Thursday, October 18, 2012 8:22:47 AM
>> Subject: Re: [katello-devel] moving to ruby 1.9.3
>>
>> On Thu, Oct 18, 2012 at 08:14:42AM -0400, 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 :)
>>>>
>>>>
>>>> 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
>> This is exactly the mode we are pushing to in Aeolus. I should point
>> out
>> that it is not only the normal mode for upstream Ruby projects, it is
>> the normal mode for *almost all* upstream projects that are not
>> completely Red-Hat centric.
>>
>> libvirt is a good example of this. It is a C project, as you know,
>> and
>> Red Hat delivers it entirely packaged as RPM. But Daniel Veillard,
>> the
>> libvirt maintainer, *will not even allow rpm spec files* in the
>> libvirt
>> tree upstream, just as he does not allow debian package
>> instructions. libvirt upstream is delivered and installed with tar
>> -xvzf
>> libvirt.tgz; ./configure; make; make install.
>>
>> The libvirt crew, because they work for Red Hat, also get to spend a
>> good bit of time maintaining the Fedora and RHEL rpm specs. This is
>> an
>> overhead investment that is worth the effort because it makes it
>> easier
>> for Red Hat to deliver libvirt. The libvirt crew *also* spend some
>> amount of time maintaining the .deb build, becasue it's good for
>> community adoption, but this is also done out of band. Core libvirt
>> contributors however do not get concerned with packaging.
>>
>> I see no reason why any of our Ruby projects should follow a
>> different
>> development mode than this.
>>
>> --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
>>
>> _______________________________________________
>> 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
--
Ivan
More information about the katello-devel
mailing list