Except the following really wasn't that hard to build in, so I'd
question the 'heavily biased' statement (it was not designed by me and
the community to be heavily biased to any specific way of doing things).
;-)
'Begin building virtualenvs for each component'
https://review.openstack.org/#/c/126447/
'Debian packaging for anvil - NOT READY FOR REVIEW'
https://review.openstack.org/#/c/87875/
-Josh
Craig Tracey 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.
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.
3) As mentioned earlier, the naming of the package is entirely up to you
- also something that may be defined in the manifest.
Hope that helps,
Craig
On Wed, Nov 19, 2014 at 3:38 PM, Kris G. Lindgren <klindg...@godaddy.com
<mailto:klindg...@godaddy.com>> wrote:
I am also interested in the packaging discussion.
As many of you guys already know, we use anvil
https://github.com/stackforge/anvil 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.
The spec files are based upon rdo's spec files, so generated
packages work correctly with upstream puppet modules.
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:
1.) Build rpms
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
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.
I am not against modifying our workflow to make venvs work for us as
well.
____________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.
From: Craig Tracey <cr...@craigtracey.com
<mailto:cr...@craigtracey.com>>
Date: Wednesday, November 19, 2014 at 12:59 PM
To: Adam Young <ayo...@redhat.com <mailto:ayo...@redhat.com>>
Cc: "openstack-operators@lists.openstack.org
<mailto:openstack-operators@lists.openstack.org>"
<openstack-operators@lists.openstack.org
<mailto:openstack-operators@lists.openstack.org>>
Subject: Re: [Openstack-operators] Operations project: Packaging
Thanks Michael for continuing this conversation. This is something
that we are particularly interested and involved in.
A while back (around the first Ops mid-cycle), I along with John
Dewey started a project called giftwrap
https://github.com/blueboxgroup/giftwrap. 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.
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.
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.
This code, along with the accompanying configuration management is
working in test and should land in both Giftwrap and our Ansible
playbooks dubbed Ursula https://github.com/blueboxgroup/ursula shortly.
Long story short, we are very interested in continuing to build
community around packaging.
Thanks again,
Craig
On Tue, Nov 18, 2014 at 7:37 AM, Adam Young <ayo...@redhat.com
<mailto:ayo...@redhat.com>> wrote:
On 11/18/2014 01:16 AM, Michael Chapman wrote:
Hi all,
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.
The Friday session indicates that as operators we have common
requirements:
A system that takes the sources from upstream projects and
produces artifacts (packages or images).
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.
RDO is the single largest "packager" of RPMs for OpenStack.
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.
- Michael
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto:OpenStack-operators@lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
<mailto: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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
