<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 22, 2014 at 5:08 AM, Michael Chapman <span dir="ltr"><<a href="mailto:woppin@gmail.com" target="_blank">woppin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Nov 20, 2014 at 8:51 AM, Craig Tracey <span dir="ltr"><<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great input Kris. We also took a look at Anvil, and as you mention it is heavily biased for RH based distros. <div><br></div><div>With regard to your requirements:</div><div>1) Under the cover for Giftwrap we use fpm for package creation, so debs and rpms are merely a flag to toggle.</div></div></blockquote><div><br></div></span><div>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?</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div></span><div>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?</div></div></div></div></blockquote><div><br></div><div>Giftwrap does not build native third-party packages. It is specifically focused on delivering artifacts for OpenStack. There are a number of cases where we need to build native packages as well, but we are using the standard Ubuntu tooling for doing so. The incidence for us needing this, though, is quite small.</div><div><br></div><div>I do not think that any tool(s) that we converge around should be dealing with third party/system packaging. This would almost certainly introduce a slew of new items to support as well as incompatibilities/edge cases between distros.</div><div><br></div><div>my 2c...</div><div>craig</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>3) As mentioned earlier, the naming of the package is entirely up to you - also something that may be defined in the manifest.</div><div><br></div><div>Hope that helps,</div><div>Craig</div></div><div><div><div class="gmail_extra"><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 19, 2014 at 3:38 PM, Kris G. Lindgren <span dir="ltr"><<a href="mailto:klindgren@godaddy.com" target="_blank">klindgren@godaddy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>
<div>I am also interested in the packaging discussion.</div>
<div><br>
</div>
<div>As many of you guys already know, we use anvil <a href="https://github.com/stackforge/anvil" target="_blank">https://github.com/stackforge/anvil</a> for building of our packages. The tool is currently geared towards Redhat, however it will also build all of the required
pip deps as packages as well. It also has all the hooks in place that are needed to work with deb's however the main users of it are primarily centos based. It also, recently, has the ability to build venvs for the packages as well, however we currently
uses packages vs's venvs.</div>
<div><br>
</div>
<div>The spec files are based upon rdo's spec files, so generated packages work correctly with upstream puppet modules.</div>
<div><br>
</div>
<div>While I am not biased towards any tools set – For a tool to replace anvil for us it needs to be able to do the following:</div>
<div>1.) Build rpms</div>
<div>2.) Allows us to carry our own patch sets. Either by building from our own git repo or by supplying patch files that are integrated at either download or package build time on top of the upstream git repo</div>
<div>3.) Control the naming of the package, so that upgrades can easily happen (IE yum update). PBR really sucks at generating package names that can be easily upgraded when working of a git branch.</div>
<div><br>
</div>
<div>I am not against modifying our workflow to make venvs work for us as well.</div>
<div>
<div>
<div>____________________________________________</div>
<div> </div>
<div>Kris Lindgren</div>
<div>Senior Linux Systems Engineer</div>
<div>GoDaddy, LLC.</div>
</div>
<div><br>
</div>
</div>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Craig Tracey <<a href="mailto:craig@craigtracey.com" target="_blank">craig@craigtracey.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, November 19, 2014 at 12:59 PM<br>
<span style="font-weight:bold">To: </span>Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>" <<a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack-operators] Operations project: Packaging<br>
</div>
<div><br>
</div>
<div>
<div><div><div>
<div dir="ltr">Thanks Michael for continuing this conversation. This is something that we are particularly interested and involved in.
<div><br>
</div>
<div>A while back (around the first Ops mid-cycle), I along with John Dewey started a project called giftwrap
<a href="https://github.com/blueboxgroup/giftwrap" target="_blank">https://github.com/blueboxgroup/giftwrap</a>. The primary objective was to build artifacts (in our first use case, debs) so that we could easily ship reliable OpenStack bits to our various OpenStack
fleets, while not being beholden to a distro. I looked around at the available options in stackforge, and each of them didn't really suit my needs. Similarly, at the Ops midcycle it was clear that this was a concern for others as well. Hence, we started
the project.</div>
<div><br>
</div>
<div>The project has progressed quite a bit from there. Now, in addition to packages it can create Docker images with the projects and source that you care about. It can gather hard pip dependencies from what passed acceptance in gate. You can add arbitrary
python and system dependencies (ie. you have SAN XYZ and their Cinder driver is not upstreamed yet) to the package or Docker image. And, all of the code is built within virtualenvs so that we can prevent cross-project dependency conflicts. Pathing is completely
customizable with Jinja templating syntax. What is nice about this is that you can lay services side-by-side in order to facilitate in-place upgrades (ie. /opt/openstack-icehouse and /opt/openstack-juno). All of these settings are defined in a yaml manifest
file.</div>
<div><br>
</div>
<div>The code today is certainly biased towards Ubuntu, but there is nothing preventing the support of other distros. All of the hooks are there...it's just a matter of time before we tackle those. We would be happy to have contributions from others interested
in this or other features.</div>
<div><br>
</div>
<div>This code, along with the accompanying configuration management is working in test and should land in both Giftwrap and our Ansible playbooks dubbed Ursula
<a href="https://github.com/blueboxgroup/ursula" target="_blank">https://github.com/blueboxgroup/ursula</a> shortly.</div>
<div><br>
</div>
<div>Long story short, we are very interested in continuing to build community around packaging.</div>
<div><br>
</div>
<div>Thanks again,</div>
<div>Craig</div>
</div>
</div></div><div class="gmail_extra"><br>
<div class="gmail_quote"><div><div>On Tue, Nov 18, 2014 at 7:37 AM, Adam Young <span dir="ltr">
<<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div><span>
<div>On 11/18/2014 01:16 AM, Michael Chapman wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>Packaging was one of the biggest points of interest in the Friday Paris meeting, and I'd like to use this thread to have a centralised discussion and/or argument regarding whether there is a packaging system that is flexible enough that we can adopt it
as a community and reduce the fragmentation. This conversation began in Paris, but will likely continue for some time.</div>
<div><br>
</div>
<div>The Friday session indicates that as operators we have common requirements:</div>
<div><br>
</div>
<div>A system that takes the sources from upstream projects and produces artifacts (packages or images).</div>
<div><br>
</div>
<div>There are numerous projects that have attempted to solve this problem. Some are on stackforge, some live outside. If you are an author or a user of one of these systems, please give your opinion.</div>
</div>
</blockquote>
</span>RDO is the single largest "packager" of RPMs for OpenStack. <br>
<br>
<br>
</div></div><blockquote type="cite"><div><div><span>
<div dir="ltr">
<div><br>
</div>
<div>Once it becomes clear who is interested in this topic, we can create a working group that will move towards standardising on a single system that meets the needs of the community. Once the key individuals for this project are clear, we can schedule an
appropriate meeting time on irc for further discussion that will probably be needed.</div>
<div><br>
</div>
<div> - Michael</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset> <br>
</span></div></div><span>
<pre>_______________________________________________
OpenStack-operators mailing list
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a></pre>
</span></blockquote>
<br>
</div><span>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</span></blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></blockquote></div><br></div></div>