Derek: Very cool! I think you may have linked me to this ages ago when it was still forming. The doc links in the README are broken but that's almost exactly what I'm (personally) looking for - a small wrapper around rpm build and some specs as repos I can fork and contribute back to where suitable.
Chris: I can appreciate the appeal of a single tool. It does add a lot of complexity. Craig: Understood. The system I'm using at Cisco is similar - farming off native builds to a verbatim copy of the ubuntu build tools. The question for me is if I have to replicate the native build tools anyway, why treat OpenStack differently? All: I'm going to make a wiki page over the weekend with a summary of the discussion so far and a feature matrix, and look at setting a time for an irc discussion to continue the discussion over the choices we have available. I'm almost certain I won't be able to be present since my timezone is AEST and I'll try to make it sometime that's friendly to EU/US, so if anyone would like to put their hand up to moderate that please let me know. There's an #openstack-stable irc channel on freenode that might be a suitable host. - Michael On Mon, Nov 24, 2014 at 11:20 PM, Chris Ricker <chris.ric...@gmail.com> wrote: > > On Nov 22, 2014, at 5:08 AM, Michael Chapman <wop...@gmail.com> wrote: > > > > On Thu, Nov 20, 2014 at 8:51 AM, Craig Tracey <cr...@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 > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
