candlepin as rpm

Adam Young ayoung at redhat.com
Thu Apr 8 13:03:06 UTC 2010


On 04/08/2010 08:54 AM, Adam Young wrote:
> On 04/08/2010 08:50 AM, Adam Young wrote:
>    
>> On 04/07/2010 11:14 PM, Jesus M. Rodriguez wrote:
>>
>>      
>>> On Wed, Apr 7, 2010 at 6:21 PM, Adam Young<ayoung at redhat.com>    wrote:
>>>
>>>
>>>        
>>>>> How hard are the above issues to address?
>>>>>
>>>>> 1. is trivial will be done probably before you read this email.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> Is this a debug thing?  You should be able to deploy the .war file
>>>> directly to the server/depoly directory in JBoss.
>>>>
>>>>
>>>>          
>>> No, it's more of an RPM thing. It allows you to own the directory that
>>> gets exploded and when you remove the rpm it takes it with it.
>>> It also helps in being able to create rpms that depend on the candlepin rpm
>>> which can lay down jars in /path/to/deploy/candlepin/WEB-INF/lib/ making it
>>> a lot easier to deploy service implementations.
>>>        

I'd be prone to install into a different directory, like something under 
/usr/share, and then copy the deploy directory as a deliberate decision 
on the part of the sys admin.  THis allows you to separate out the 
copying of the code to the machine and the upgrade.   JBoss hot deploy 
is a pretty nice feature, and, so long as there is not a DB upgrade 
involved, goes pretty cleanly.  One caveat is that the deploy dir should 
be on the same volume as the jar.  It it is, deploy is just a rename, 
which is atomic,  otherwise it is a full copy, and JBoss will start 
deploying as soon as it knows that the the deploy dir has a new dentry.


THus, I'd suggest the folowing:


/usr/share/candlepin/candelin.war
/usr/share/candlepin/upgrade.sh

And then, as part of deploy:

Check for DB upgrades.  IF there are any, undeploy candlepin from JBoss, 
upgrade the DB

For deploy, create a dir jbossas/server/deploy-stage right next to 
jbossas/server/deploy
cp candlepin.war to jbossas/server/deploy-stage
mv jbossas/server/deploy-stage jbossas/server/deploy






>>>
>>>
>>>        
>>>>> 2. this is a bit more difficult because we need a way to update
>>>>>        the candlepin_info.properties on the fly and the build isn't
>>>>>        running in a git checkout at the time of the rpm build.
>>>>>
>>>>>        How important is the candlepin_info.properties with a git hash?
>>>>>
>>>>> 3. requiring rubygem-buildr is the proper way to do it, but if the
>>>>>        rpm isn't ready for folks to deploy, then the candlepin rpm
>>>>>        won't be buildable yet.
>>>>>
>>>>>        Changing it to require /usr/bin/buildr will make it buildable
>>>>>        now and *will* require changing once we have a proper rpm of
>>>>>        buildr.
>>>>>
>>>>>        An alternative is to BuildRequires: ant, add a build.xml to build
>>>>>        the code just for the rpm. (sorry I ain't doing no  maven rpm).
>>>>>
>>>>>        I'm leaning towards simply requiring /usr/bin/buildr for now, and
>>>>>        merge it into master for now with a new item to finalize the
>>>>>        buildr rpm.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> The Buildr RPM works now, so long as we don't need to run the cucumber
>>>> tests.  All RPMS required are in :
>>>> http://admiyo.fedorapeople.org/buildr/RPMS/
>>>>
>>>> I'll eventually get a Yum repo set up, but wget those and install should
>>>> work for now, so long as you haven't run
>>>> "ruby system --update"
>>>>
>>>>
>>>>          
>>> Ok I'll update my rpms. If you want to you could just run createrepo -d
>>> on the directory you have those RPMS in and then rsync the repo metadata
>>> files to your people account. Unless you don't want a repo right now for
>>> some reason.
>>>
>>>
>>>        
>> Yeah, I did that on my local machine.  No createrepo on the remote, so
>> I'll rsync over from local.
>>
>>      
> http://admiyo.fedorapeople.org/buildr-repo/
>
>
>    
>>>
>>>        
>>>>> 4. I think the best way is to *pass* in the version number to the
>>>>>        build command from the spec file, and have the buildfile read
>>>>>        the version from the spec file during dev builds.
>>>>>
>>>>>        In other words, in the candlepin.spec the %build section will look
>>>>>        as follows: buildr clean test=no package version=%{version}
>>>>>
>>>>>        I'm not sure if this is even possible on the buildr side, but since
>>>>>        it can do anything ruby and rake can, it's probably doable.
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> I'm not sure I understand the issue here.
>>>>
>>>>
>>>>          
>>> the buildfile has a VERSION=1.0.0 which NEVER changes. And
>>> the candlepin.spec file has a Version=1.0.1 (which is incremented by
>>> tito during the tagging process. It would be best if we kept them
>>> consistent. To me the buildfile should use the one passed in from
>>> the rpm during build, and for development purposes i.e. buildr package
>>> from your git tree it should use the git hash as the version number.
>>>
>>>
>>> jesus
>>> _______________________________________________
>>> candlepin mailing list
>>> candlepin at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>
>>>
>>>        
>> _______________________________________________
>> candlepin mailing list
>> candlepin at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
>>      
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>    




More information about the candlepin mailing list