[katello-devel] where to get required katello gems

Mike McCune mmccune at redhat.com
Mon Jul 16 16:42:36 UTC 2012


On 07/16/2012 06:51 AM, Bryan Kearney wrote:
> On 07/16/2012 09:43 AM, Hugh O. Brock wrote:
>> On Mon, Jul 16, 2012 at 09:28:44AM -0400, Michael Orazi wrote:
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bryan Kearney"<bkearney at redhat.com>
>>>>> To: katello-devel at redhat.com
>>>>> Sent: Monday, July 16, 2012 8:23:25 AM
>>>>> Subject: Re: [katello-devel] where to get required katello gems
>>>>>
>>>>> On 07/16/2012 07:26 AM, Petr Chalupa wrote:
>>>>>> I have a counter proposal which is more from Ruby world then the
>>>>>> solution described in previous emails.
>>>>>>
>>>>>> - remove source
>>>>>> 'http://repos.fedorapeople.org/repos/katello/gems/'
>>>>>> and
>>>>>> other sources from Gemfile
>>>>>> - store all needed gems in vendor/cache as .gem files (directly
>>>>>> in
>>>>>> katello master or a git-submodule) (all versions for f16 and
>>>>>> RHEL)
>>>>>> - install gems with bundle install (without source specified
>>>>>> bundler
>>>>>> picks up gems from vendor/cache)
>>>>>>
>>>>>> Advantages:
>>>>>> - you can install all required gems on any platform: fedora,
>>>>>> ubuntu
>>>>>> or
>>>>>> osx (which I need)
>>>>>> - faster installation
>>>>>> - you can switch between fedora/RHEL env by replacing
>>>>>> Gemfile.lock
>>>>>> (lets
>>>>>> say we would have Gemfile.lock.f16 and Gemfile.lock.rhel in our
>>>>>> git
>>>>>> for
>>>>>> this purpose)
>>>>>> - easy access to and updates of gem versions
>>>>>> - you can include gems with CVE patches from fedora, everybody
>>>>>> would
>>>>>> have correct versions of gems (which I currently don't have)
>>>>>>
>>>>>> Disadvantages
>>>>>> - rubygem-* rpms are not being correctly packed. The included
>>>>>> .gem
>>>>>> files
>>>>>> are not containing CVE patches. We would need to come up with a
>>>>>> workaround to build updated .gem files or fix the issue. If this
>>>>>> is
>>>>>> fixed, all you have to do to store gems in vendor/cache is
>>>>>> 'bundle
>>>>>> package' [1].
>>>>>> - other possible problems i do not see, any ideas?
>>>>>>
>>>>>> [1] http://gembundler.com/bundle_package.html
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Petr
>>>>>>
>>>>>
>>>>> Could we do this model for DEV, and then work on proper packaging
>>>>> for
>>>>> each distro? I think it would help alot if we could be more
>>>>> friendly
>>>>> to
>>>>> DEVs.
>>>>>
>>>>> -- bk
>>>>>
>>>>> _______________________________________________
>>>>> katello-devel mailing list
>>>>> katello-devel at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>>
>>>>
>>>> I said half jokingly on IRC the other day that we should have a
>>>> 'katello-configure --developer' which would install everything for
>>>> use with a git checkout. This would make it completely simple for
>>>> anyone to get up and going with a dev setup. Perhaps they would just
>>>> point to the git checkout:
>>>>
>>>> % katello-configure --developer /home/dudette/katello
>>>>
>>>> _______________________________________________
>>>> katello-devel mailing list
>>>> katello-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>
>>>
>>> There have been some similar discussions on aeolus-devel as well.  Perhaps we could put our heads together and come up with a common solution for both projects since we are dealing with similar concerns.
>>>
>>> Adding John Eckersberg and Jason Guiditta to the cc as they have been thinking a bit about both of these problems.  John has been pretty focussed on possible integrations in aeolus-configure and Jason has been working quite a bit about how to handle bundler such that it will act as one would expect regardless of whether they are an 'rpm based' developer or a 'pure ruby' developer.
>>>
>>> Mike
>>
>> Yes. I really, really, really want to get all traces of distro
>> packaging *out* of the Aeolus upstream, which would imply that a. A
>> developer can check out the code base, do $THINGS, and run a dev
>> server, and b. a user can download a tarball, do $THINGS, and launch a
>> functioning instance, regardless of which platform they're on (as long
>> as the platform has a functioning Ruby environment, so Windows is
>> maybe out but who really cares).
>>
>> I'm more than happy to give John and Jay extra time to get this right,
>> if somebody on the Katello team wants to help that would be awesome.
>>
>> Take care,
>> --Hugh
>>
> I agree in principal, with the exception of the back end engines (Pulp,
> Candlepin etc). They wil need to be installed $SOMEHOW. But, I do like
> the idea of the rails app being (in DEV mode) as DISTRO neutral as possible.

we can always point at a different host.  If you don't want to run 
candlepin and pulp on your dev box, run them somewhere else.  Back in 
the beginning a few devs worked this way.

$ katello-configure --development /home/blah/devel/katello 
--candlepinhost=somecandlepinhost.example.com 
--pulphost=pulphost.example.com

Mike




More information about the katello-devel mailing list