<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">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 class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <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>
    <blockquote type="cite"><span class="">
      <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><span class=""><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>

<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>