[Openstack-operators] Operations project: Packaging

Chris Ricker chris.ricker at gmail.com
Mon Nov 24 12:20:18 UTC 2014


> On Nov 22, 2014, at 5:08 AM, Michael Chapman <woppin at gmail.com> wrote:
> 
> 
> 
>> On Thu, Nov 20, 2014 at 8:51 AM, Craig Tracey <craig at craigtracey.com> wrote:
>> Great input Kris.  We also took a look at Anvil, and as you mention it is heavily biased for RH based distros.  
>> 
>> With regard to your requirements:
>> 1) Under the cover for Giftwrap we use fpm for package creation, so debs and rpms are merely a flag to toggle.
> 
> During the Paris session someone specifically mentioned they didn't want to use fpm, and wanted plain spec files instead. If that person is on this list, or if there's anyone else in that position, care to elaborate? Is there a specific limitation people are concerned about?
>  

We get this request pretty commonly - the most common use case I hear like this is people who want to start with a "reference" build (RDO / OSP, UCA, etc) and minimally customize. So they want to stay with the original spec or debian/* packaging and tweak, vs package de novo


>> 2) Giftwrap is targeted for precisely this workflow.  We pull our OpenStack source from a forked git repo, with any patches applied.  The giftwrap manifest allows for specification of repo as well as ref.
> 
> I asked you about this in Paris, but for the benefit of the list, what about native packages? I find I need to package things like libvirt as well. As a community are we expecting to run one packaging tool for Openstack's python packages and one tool for everything else, or do we expect that to be combined into a single tool that can handle both?
>  

Strong preference for same tool doing both. Which couples with the above point to land on "need a generic rpm / deb builder" at least for those use cases

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141124/f00ada28/attachment.html>


More information about the OpenStack-operators mailing list