Re: [Openstack-operators] Operations project: Packaging

2014-12-01 Thread Fischer, Matt
.openstack.org>" mailto:openstack-operators@lists.openstack.org>> Subject: Re: [Openstack-operators] Operations project: Packaging I've started a wiki page here, please feel free to flesh it out with more detail: https://wiki.openstack.org/wiki/Packaging/GenericTooling Looking at

Re: [Openstack-operators] Operations project: Packaging

2014-11-30 Thread Michael Chapman
> güncellemenizi rica ediyoruz. >> >> http://visitor.r20.constantcontact.com/manage/optin?v=001t9egDEMH10MEulnTu-Lzln0RXbiYIgR2HnLd_hpHmPb0K44ZxJOya0FvCOF3TI8c2qeErt1Xrn3PlZqntTSqiSTW40PTK2XQ8OlOUe4qYOE%3D >> >> -Original Message- >> From: Derek Higgins [ma

Re: [Openstack-operators] Operations project: Packaging

2014-11-30 Thread George Shuklin
..@redhat.com>] Sent: Friday, November 28, 2014 12:35 PM To: Jay Pipes; openstack-operators@lists.openstack.org <mailto:openstack-operators@lists.openstack.org> Subject: Re: [Openstack-operators] Operations project: Packaging On 27/11/14 15:06, Jay Pipes wrote

Re: [Openstack-operators] Operations project: Packaging

2014-11-30 Thread Michael Chapman
ins [mailto:der...@redhat.com] > Sent: Friday, November 28, 2014 12:35 PM > To: Jay Pipes; openstack-operators@lists.openstack.org > Subject: Re: [Openstack-operators] Operations project: Packaging > > On 27/11/14 15:06, Jay Pipes wrote: > > On 11/24/2014 06:58 AM, Derek Higgins wr

Re: [Openstack-operators] Operations project: Packaging

2014-11-28 Thread Emrah Aslan
Pipes; openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] Operations project: Packaging On 27/11/14 15:06, Jay Pipes wrote: > On 11/24/2014 06:58 AM, Derek Higgins wrote: >> On 18/11/14 06:16, Michael Chapman wrote: >>> Hi all, >>> >>> Pac

Re: [Openstack-operators] Operations project: Packaging

2014-11-28 Thread Derek Higgins
On 27/11/14 15:06, Jay Pipes wrote: > On 11/24/2014 06:58 AM, Derek Higgins wrote: >> On 18/11/14 06:16, 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 >>> discussi

Re: [Openstack-operators] Operations project: Packaging

2014-11-27 Thread Jay Pipes
On 11/24/2014 06:58 AM, Derek Higgins wrote: On 18/11/14 06:16, 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

Re: [Openstack-operators] Operations project: Packaging

2014-11-27 Thread George Shuklin
On Thu, Nov 20, 2014 at 8:51 AM, 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 p

Re: [Openstack-operators] Operations project: Packaging

2014-11-27 Thread Michael Chapman
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

Re: [Openstack-operators] Operations project: Packaging

2014-11-24 Thread Chris Ricker
> On Nov 22, 2014, at 5:08 AM, Michael Chapman wrote: > > > >> On Thu, Nov 20, 2014 at 8:51 AM, 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

Re: [Openstack-operators] Operations project: Packaging

2014-11-24 Thread Derek Higgins
On 18/11/14 06:16, 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

Re: [Openstack-operators] Operations project: Packaging

2014-11-22 Thread Craig Tracey
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. &

Re: [Openstack-operators] Operations project: Packaging

2014-11-22 Thread Michael Chapman
t; >> >> Kris Lindgren >> Senior Linux Systems Engineer >> GoDaddy, LLC. >> >> >> From: Craig Tracey >> Date: Wednesday, November 19, 2014 at 12:59 PM >> To: Adam Young >> Cc: "openstack-operato

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Jeremy Stanley
On 2014-11-19 21:25:49 + (+), Kris G. Lindgren wrote: > PBR when working off of a branch uses the git hash of the commit for the > version of the package. So you will get a version name like > openstack-nova-2014.1.2-{githash} [...] > The behavior that I would change is to allow you to ove

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Kris G. Lindgren
To get around the PBR versioning issue right now we use annotated tags for each "release" that we build and then we update the release number inside anvil for that component to be one higher than the current package. So that we get sanely tagged/versioned packages. For example, our version of nova

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Mathieu Gagné
On 2014-11-19 5:01 PM, Joshua Harlow wrote: That sort of makes the operator/package builder then solely responsible for knowing what the versions should be right? Once used it becomes no longer pbr's job to figure out a right version, which works ok as long as u have the appropriate infrastructur

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Joshua Harlow
ilto:cr...@craigtracey.com>> Date: Wednesday, November 19, 2014 at 12:59 PM To: Adam Young mailto:ayo...@redhat.com>> Cc: "openstack-operators@lists.openstack.org <mailto:openstack-operators@lists.openstack.org>" mailto:openstack-operators@l

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Joshua Harlow
That sort of makes the operator/package builder then solely responsible for knowing what the versions should be right? Once used it becomes no longer pbr's job to figure out a right version, which works ok as long as u have the appropriate infrastructure to do this correctly (and meticulously f

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Craig Tracey
___ > > Kris Lindgren > Senior Linux Systems Engineer > GoDaddy, LLC. > > > From: Craig Tracey > Date: Wednesday, November 19, 2014 at 12:59 PM > To: Adam Young > Cc: "openstack-operators@lists.openstack.org" < > open

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Mathieu Gagné
On 2014-11-19 4:25 PM, Kris G. Lindgren wrote: Sure. PBR when working off of a branch uses the git hash of the commit for the version of the package. So you will get a version name like openstack-nova-2014.1.2-{githash}, which is used by other tools to set the name of the package (such as anvil

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Clint Byrum
Excerpts from Michael Chapman's message of 2014-11-17 22:16:28 -0800: > 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 th

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Kris G. Lindgren
Sure. PBR when working off of a branch uses the git hash of the commit for the version of the package. So you will get a version name like openstack-nova-2014.1.2-{githash}, which is used by other tools to set the name of the package (such as anvil). So when you build a new package and the githa

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Jeremy Stanley
On 2014-11-19 20:38:58 + (+), Kris G. Lindgren wrote: [...] > PBR really sucks at generating package names that can be easily > upgraded when working of a git branch. [...] Can you elaborate (or open a bug) on which behaviors you would alter and how? PBR is trying to streamline workflow fo

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Kris G. Lindgren
at 12:59 PM To: Adam Young mailto:ayo...@redhat.com>> Cc: "openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" mailto:openstack-operators@lists.openstack.org>> Subject: Re: [Openstack-operators] Operations project: Packaging Thanks M

Re: [Openstack-operators] Operations project: Packaging

2014-11-19 Thread Craig Tracey
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 b

Re: [Openstack-operators] Operations project: Packaging

2014-11-18 Thread Adam Young
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 w

Re: [Openstack-operators] Operations project: Packaging

2014-11-17 Thread Xav Paice
On 18/11/14 19:16, 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

[Openstack-operators] Operations project: Packaging

2014-11-17 Thread Michael Chapman
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 fragmen