Re: [openstack-dev] [tripleo][ui] Dependency management

2018-03-02 Thread Alan Pevec
On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichon wrote: > On 19 January 2018 at 18:43, Honza Pokorny wrote: >> We've recently discovered an issue with the way we handle dependencies for >> tripleo-ui. This is an explanation of the problem, and a proposed solution. >> I'm looking for feedback. >> >>

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-03-13 Thread Alan Pevec
2017-03-13 15:49 GMT+01:00 Doug Hellmann : ... > We test this upgrade scenario in the upstream CI, too. The difference > is that grenade can tell pip "install exactly the version I am > pointing to in this directory on disk," rather than relying on > version numbers to notice that an upgrade is nee

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-03-13 Thread Alan Pevec
2017-03-09 14:58 GMT+01:00 Jeremy Stanley : > In the past we addressed this by automatically merging the release > tag back into master, but we stopped doing that a cycle ago because > it complicated release note generation. Also this was including RC >= 2 and final tags so as soon as the first st

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

2017-03-09 Thread Alan Pevec
2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso : > On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy wrote: >> https://bugs.launchpad.net/tripleo/+bug/1669462 >> >> I'm not clear on the best path forward at this point, but the simplest one >> suggested so far is to simply tag a new pre-milestone/a

Re: [openstack-dev] [Tripleo] FFE to add Congress to Triple-o

2017-02-02 Thread Alan Pevec
Waiting for Alan to give -1/+1 on the RDO side, but it's a +1 for me on the TripleO side. +1 from me, I should finish missing PuLP dependency in RDO today __ OpenStack Development Mailing List (not for usage questions) Unsubs

Re: [openstack-dev] [release][stable] nominating Alan Pevec (apevec) for stable release core

2017-01-20 Thread Alan Pevec
> Welcome to the team, Alan! Thanks all! Alan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mail

Re: [openstack-dev] [rdo-list] [RDO][DLRN] DLRN worker downtime during the weekend

2017-01-13 Thread Alan Pevec
> We need to run some maintenance operations on the DLRN instance next weekend, > starting on Friday 13 @ 19:00 UTC. I've aborted the purge and restarted Ocata master builder so we can get reverts built for CI blocker https://bugs.launchpad.net/nova/+bug/1656276 Cheers, Alan ___

Re: [openstack-dev] [ironic] [stable] Proposing Jay Faulkner for ironic-stable-maint

2016-11-22 Thread Alan Pevec
> Well, apparently I don't have access to add you, so we'll have > to wait for Tony or someone else from the stable team to do that > thing. :) Done and welcome Jay! Cheers, Alan __ OpenStack Development Mailing List (not fo

Re: [openstack-dev] [stable][release] Final releases for stable/liberty and liberty-eol

2016-11-21 Thread Alan Pevec
> 1. Final stable/liberty releases should happen next week, probably by > Thursday 11/17. I see only Cinder did it https://review.openstack.org/397282 and Nova is under review https://review.openstack.org/397841 Is that all or other project are not aware Liberty is EOL now? Cheers, Alan ___

Re: [openstack-dev] [tripleo] possible backports for stable/newton

2016-11-09 Thread Alan Pevec
> Since our cherry picks don't seem to be considered equivalents by git > (probably because of modified commit messages) I'd like to understand why is that, do you have an example? It should work when recommendation[*] is followed. Cheers, Alan [*] http://docs.openstack.org/project-team-guide/

Re: [openstack-dev] [packstack] Proposal to add Alfredo Moralejo as core reviewer

2016-10-29 Thread Alan Pevec
> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core > reviewer for Packstack. +1 With Alfredo in packstack-core, Spanish-speaking population will gain relative majority and we should totally rename it to Packistack ;) Cheers, Alan ___

[openstack-dev] [release] RDO Newton packages released

2016-10-06 Thread Alan Pevec
The RDO community is pleased to announce the general availability of the RDO build for OpenStack Newton for RPM-based distributions - CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Newton is the 14th release from the OpenStack project (

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

2016-09-22 Thread Alan Pevec
2016-09-22 15:58 GMT+02:00 Matt Riedemann : > 1. We don't bump minimums just because a new thing comes out in a given > release, we only bump minimums when something that uses that dependency > needs a higher minimum version. > > 2. Looking at this: > > https://github.com/openstack/releases/blob/ma

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

2016-09-22 Thread Alan Pevec
> We have: > * global-requirements.txt: > origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 But wasn't that wrong from the start? First Liberty release of oslo.concurrency was 2.6.0 why was that not bumped in g-r ? Cheers, Alan

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

2016-09-20 Thread Alan Pevec
2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy : >> (3) Do nothing, leave the bug unfixed in stable/liberty > > That was the unspoken third option, thanks for spelling it out. :-) Yes, let's abandon both reviews. Cheers, Alan __

Re: [openstack-dev] [oslo.db] [release] opportunistic tests breaking randomly

2016-09-14 Thread Alan Pevec
> Olso.db 4.13.3 did hit the scene about the time this showed up. So I > think we need to strongly consider blocking it and revisiting these > issues post newton. So that means reverting all stable/newton changes, previous 4.13.x have been already blocked https://review.openstack.org/365565 How wo

Re: [openstack-dev] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group

2016-09-02 Thread Alan Pevec
+1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

2016-07-21 Thread Alan Pevec
On Thu, Jul 21, 2016 at 12:42 PM, Derek Higgins wrote: > Trying to catch up here and summarizing as a top post ack for the summary > either of these, based only on which was proposed first i'd go for > 345070 ack, I've abandoned 345106 > Start a discussion in rdo about how exactly people expec

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

2016-07-20 Thread Alan Pevec
On Wed, Jul 20, 2016 at 7:49 PM, Sagi Shnaidman wrote: > How then it worked before? Can you show me the patch that broke this > functionality in delorean? It should be about 15 Jul when jobs started to > fail. commented in lp > How then master branch works? It also runs on patched repo and succe

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

2016-07-20 Thread Alan Pevec
> as a quickfix in tripleo.sh you could patch dlrn and set local=True in correction, patch local=False there while running dlrn command with --local to keep source checkout as-is __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

2016-07-20 Thread Alan Pevec
>> ^ ... --local here keeps local checkout untouched, so you end up with >> default rpm-master in distro git checkout. >> If you remove --local it will reset local checkouts to the branches >> specified in projects.ini >> > Alan, > I don't want to reset local checkouts and reset branches - I need t

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

2016-07-20 Thread Alan Pevec
> git clone https://git.openstack.org/openstack/tripleo-heat-templates > cd tripleo-heat-templates/ > git checkout -b stable/mitaka origin/stable/mitaka ^ this is manually switching to the stable source branch > sed -i -e "s%distro=.*%distro=rpm-mitaka%" projects.ini > sed -i -e "s%source=.*%sour

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-03 Thread Alan Pevec
> openstack/packstack BigTent Just to clarify, Packstack has not formally applied to BigTent yet, it has only been automatically migrated from stackforge to openstack namespace. But yes, please keep its kilo branch for now until we properly wrap it up. Cheers,

Re: [openstack-dev] [packstack] Update packstack core list

2016-04-13 Thread Alan Pevec
>> I would like to step up as PTL if everybody is ok with it. > > Go for it Iván! +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

2016-03-24 Thread Alan Pevec
> So, if Delorean includes packages built from untagged commits in Nit clarification: let's call it RDO Trunk repository (Delorean is a tool, recently renamed https://github.com/openstack-packages/dlrn ) > multiple branches, placed in the same package repository where an > automated installation

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

2016-03-24 Thread Alan Pevec
2016-03-24 2:21 GMT+01:00 Robert Collins : > Trunk will rapidly exceed mitaka's versions, leading to no confusion too. That's the case now, RC1 tags are reachable from both branches and master has more patches, generating higher .devN part. But once RC2 and final tags are pushed, generated version

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

2016-03-22 Thread Alan Pevec
> The release team discussed this at the summit and agreed that it didn't > really matter. The only folks seeing the auto-generated versions are those > doing CD from git, and they should not be mixing different branches of a > project in a given environment. So I don't think it is strictly nece

[openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

2016-03-22 Thread Alan Pevec
2016-02-26 19:51 GMT+01:00 Robert Collins : > On 27 February 2016 at 00:13, Neil Jerram wrote: >> I understand the semantic versioning algorithm for calculating a new >> version. But what do I run, in a git repository, to do that calculation >> for me, and output: > > pbr does that automatically,

Re: [openstack-dev] How do I calculate the semantic version prior to a release?

2016-03-18 Thread Alan Pevec
2016-02-29 9:32 GMT+01:00 Thomas Bechtold : >> >> python setup.py rpm_version >> > >> > The output for i.e. for Manila is here "1...b3.dev138" And in Tempest rpm_version outputs 4.0.0.dev22 while setup.py --version says 10.0.1.dev79 ?! >> > Which is not really correct. The version is "2

Re: [openstack-dev] [packstack] Update packstack core list

2016-03-16 Thread Alan Pevec
2016-03-16 11:23 GMT+01:00 Lukas Bezdicka : >> ... >> - Martin Mágr >> - Iván Chavero >> - Javier Peña >> - Alan Pevec >> >> I have a doubt about Lukas, he's contributed an awful lot to >> Packstack, just not over the last 90 days. Lukas,

[openstack-dev] [stable] Stable* wiki updates

2016-03-10 Thread Alan Pevec
Hi stable-maints, FYI I've updated https://wiki.openstack.org/wiki/StableBranch and https://wiki.openstack.org/wiki/StableBranchRelease now that all policy and team information has ben included in the Project Team Guide. Please review in case I missed something! Cheers, Alan

Re: [openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

2016-02-24 Thread Alan Pevec
> The tricky bit is that RDO does not include patches in our packages > built from trunk (trunk.rdoproject.org), and for liberty we first check > if stable/liberty exists, then fallback to master if it does not. So the > presence of stable/liberty that is not actually the recommended way to > build

Re: [openstack-dev] [openstack-announce] [release][stable][horizon] horizon release 8.0.1 (liberty)

2016-02-08 Thread Alan Pevec
> With package available at: > > https://pypi.python.org/pypi/horizon AFAICT non-client/non-oslo stable point releases are NOT uploaded to pypi, are they? e.g. last horizon on pypi is version 2012.2 Should we start uploading them to pypi or change the email template for services projects? Che

Re: [openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

2016-01-15 Thread Alan Pevec
2016-01-15 11:08 GMT+01:00 Dave Walker : > On 15 January 2016 at 10:01, Thierry Carrez wrote: >> Ihar Hrachyshka wrote: >>> >>> +1. CVE fixes obviously should be granted an exception. >> >> >> +1 >> > > Agreed, I have already +2'd on Gerrit. Can another core please do the same? Done and workflow

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

2015-12-08 Thread Alan Pevec
>>> I wonder how to avoid giving impression that development has stopped on >>> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as >>> we no longer push tarballs to launchpad. .0 is clear indication that's GA tarball, but to make it clear you can update Launchpad series summar

Re: [openstack-dev] [Magnum] Liberty RPMs for RDO

2015-11-30 Thread Alan Pevec
Hi Mathieu, 2015-11-30 10:54 GMT+01:00 Mathieu Velten : > Hi, > > Let me first introduce myself : I am currently working at CERN to help > evaluate and deploy Magnum. > > In this regard Ricardo recently sends an email regarding Puppet > modules, this one is about RPMs of Magnum for CentOS with RDO

Re: [openstack-dev] [stable] Post-release bump after 2014.2.4?

2015-11-26 Thread Alan Pevec
> I've confirmed that the juno side of kilo grenade is not blowing up [1], but > I'm not sure why it's not blowing up. Trying to figure that out. It would blow up if something were merged after 2014.2.4 tag which won't happen before version in setup.cfg is either bumped or removed so we're safe :)

Re: [openstack-dev] [release][stable][keystone] keystonemiddleware release 1.5.3 (kilo)

2015-11-24 Thread Alan Pevec
> keystonemiddleware 1.5.3: Middleware for OpenStack Identity periodic-ceilometer-python27-kilo started failing after this release First bad: http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-kilo/40c5453/testr_results.html.gz test_acl_scenarios failing with 401 Unauthorized

Re: [openstack-dev] [stable] Post-release bump after 2014.2.4?

2015-11-24 Thread Alan Pevec
> But to illustrate better the issue I'm seeing: > http://tarballs.openstack.org/cinder/cinder-stable-juno.tar.gz contains > a directory cinder-2014.2.4.dev24, which is kind of wrong. That's the > bit that I'd like to see fixed. That version was correct at the time tarball was generated, if it wer

Re: [openstack-dev] [stable] Post-release bump after 2014.2.4?

2015-11-23 Thread Alan Pevec
2015-11-23 17:31 GMT+01:00 Matt Riedemann : >> Or do you also suggest juno-eol != 2014.2.4? > I'd prefer to just remove the version tag in setup.cfg entirely so we switch > to post-versioning, then we can EOL the thing. That's what we do internally > on EOL stable branches (switch to post-versionin

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-20 Thread Alan Pevec
> So we were brainstorming this with Rocky the other night. Would this be > possible to do by following: > 1) we still tag juno EOL in few days time > 2) we do not remove the stable/juno branch Why not? > 3) we run periodic grenade jobs for kilo >From a quick look, grenade should work with a ju

Re: [openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

2015-11-20 Thread Alan Pevec
2015-11-20 3:22 GMT+01:00 Davanum Srinivas : > fyi https://review.openstack.org/#/c/247677/ That's not the right answer to Rochelle's plea :) It was actually already answered by Matt, with a suggestion that _Kilo_ grenade job could simply checkout 2014.2.4 tag instead of stable/juno and for that w

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-17 Thread Alan Pevec
2015-11-12 21:37 GMT+01:00 Zane Bitter : > https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:stable/juno,n,z > > It would be nice to treat the remaining 'High' priority one as a blocker. > The rest aren't a blocker for the release but it would be really nice to at > least h

[openstack-dev] [stable] Call for testing: 2014.2.4 candidate tarballs

2015-11-14 Thread Alan Pevec
Hi all, we are scheduled to publish 2014.2.4, last Juno point release, on Thursday November 19th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova, Sahara and Trove. Draft release notes are available at https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.4 We'd appreciate any

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-13 Thread Alan Pevec
> Speaking of your "hacky" patch: yes and no. It makes the gate passing, > it doesn't change the code itself. For most people, this will work fine. > > The right way to do it, would be to create a juno branch for doa and > cap requirements there. > > How to do this? Is there a procedure to request

Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-12 Thread Alan Pevec
> This is a call to stable-maint teams for Nova, Keystone, Glance, > Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review > open stable/juno changes[2] and approve/abandon them as appropriate. CCing CPLs listed in https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch

[openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-10 Thread Alan Pevec
Hi, while we continue discussion about the future of stable branches in general and stable/juno in particular, I'd like to execute the current plan which was[1] 2014.2.4 (eol) early November, 2015. release manager: apevec Iff there's enough folks interested (I'm not) in keep Juno alive longer, t

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

2015-11-10 Thread Alan Pevec
>> The Stable Branch Policy, lets not put it in any repo. >> Doing that would give indication that we expect changes into it and I'd >> prefer that policy mostly staying stable as well. What indication did it give when it was in wiki? :) > It actually already is in a repo: > http://git.openstack

Re: [openstack-dev] Do all OpenStack daemons support sd_notify?

2015-10-15 Thread Alan Pevec
Thanks for responding, does this make it longest by time duration thread ever? :) 2015-10-15 22:44 GMT+02:00 Thomas Goirand : > On 12/16/2014 11:59 AM, Alan Pevec wrote: ... >> Current implementation in oslo service sends notification only just >> before entering the wait loop,

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-10-15 Thread Alan Pevec
2015-10-14 10:59 GMT+02:00 Thierry Carrez : > Sean Dague wrote: >> I think that whoever sets the tag should also push those fixes. We had >> some kilo content bogging down the gate today because of this kind of >> failure. Better to time this as close as possible with the tag setting. > > Right. Th

Re: [openstack-dev] [all][stable][release] 2015.1.2

2015-09-24 Thread Alan Pevec
> For Horizon, it would make sense to move this a week back. We discovered > a few issues in Liberty, which are present in current kilo, too. I'd > love to cherry-pick a few of them to kilo. What are LP bug#s ? Are you saying that fixes are still work in progress on master and not ready for backpo

Re: [openstack-dev] Patches coming for .coveragerc

2015-09-22 Thread Alan Pevec
2015-09-21 16:12 GMT+02:00 Monty Taylor : > We're running a script right now to submit a change to every project with > this change. The topic will be coverage-v4 stable/kilo has uncapped coverage>=3.6 do we patch-spam it or cap coverage? stable/juno has coverage>=3.6,<=3.7.1 Cheers, Alan __

[openstack-dev] [stable] 2015.1.2 readiness check WAS : gate-trove-functional-dsvm-mysql needs some stable branch love

2015-09-21 Thread Alan Pevec
>> [1] https://bugs.launchpad.net/trove-integration/+bug/1479358 >> [2] https://review.openstack.org/#/c/207193/ This fix has been merged and bug closed but Trove on stable/kilo is not green yet, summary from https://etherpad.openstack.org/p/stable-tracker * Trove * various proboscis.case.MethodT

Re: [openstack-dev] [requirements] attention requirements-cores, please look out for constraints updates

2015-09-09 Thread Alan Pevec
> I'd like to add in a lower-constraints.txt set of pins and actually > start reporting on whether our lower bounds *work*. Do you have a spec in progress for lower-constraints.txt? It should help catch issues like https://review.openstack.org/221267 There are also lots of entries in global-requir

[openstack-dev] [depfreeze] [keystone] Set minimum version for passlib

2015-09-08 Thread Alan Pevec
Hi all, according to https://wiki.openstack.org/wiki/DepFreeze I'm requesting depfreeze exception for https://review.openstack.org/221267 This is just a sync with reality, copying Javier's description: (Keystone) commit a7235fc0511c643a8441efd3d21fc334535066e2 [1] uses passlib.utils.MAX_PASSWORD_

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-17 Thread Alan Pevec
> The only alternative seems to be to have on-demand stable-branch > tagging. The main drawbacks of that option are that consumers of the > stable branch are unnecessarily limited to specific tagged commits, and > depend on various project teams to remember to push them. As Doug suggested, stable

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

2015-08-16 Thread Alan Pevec
>> 2) Should this also be sent to centos-devel folks so that they don't >> upgrade/update the pyopenssl in their distro repos until the issue >> is resolved ? > > > I think let's give the upstream issues a little while to play-out, > then we decide our next steps around use of the library based on

Re: [openstack-dev] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

2015-08-05 Thread Alan Pevec
>> > > > To give you an idea, if we enabled that for Kilo we'd be at Nova >> > > > 11.0.80 >> > > > (kilo) and Nova 10.0.218 (juno). >> > > I am not a fan of doing this second option at all. We would be polluting >> > > the ref space of our repos with redundant information making the output >> > >

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

2015-07-30 Thread Alan Pevec
... commit fb9582acc739d7719da0f1cc5f29b9e24097e025 Author: Alan Pevec Date: Thu Jul 30 12:07:27 2015 +0200 Switch to post-versioning Change-Id: Ie4758058672bdeff86147f796d53f602a65228f1 diff --git a/setup.cfg b/setup.cfg index e8d84e3..da0edb9 100644 --- a/setup.cfg +++ b/setup.cfg @@

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

2015-07-30 Thread Alan Pevec
> The way we did it in the past was to push the setup.cfg version=2015.1.2 > bump BEFORE we tag, then once that is merged, tag the previous commit in > history as 2015.1.1. That way you avoid the lockstep (and ensure no > intermediary badly-versioned tarball can be produced). > > Any reason why tha

Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged

2015-07-29 Thread Alan Pevec
> I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. > But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again

Re: [openstack-dev] [horizon] [stable] Freeze exception

2015-07-29 Thread Alan Pevec
> I would like to request for a freeze exception for the this bug: > https://bugs.launchpad.net/horizon/+bug/1474618 > > This is the patch: > https://review.openstack.org/#/c/206184/ Too late for 2015.1.1, tags (except neutron) have been pushed but certainly fine to merge to stable/kilo. Cheers,

Re: [openstack-dev] [stable]{kilo][glance] freeze exceptions

2015-07-21 Thread Alan Pevec
> We have been waiting python-cinderclient stable/kilo release for couple of > weeks to be able to merge glance_store stable/kilo backports. Namigly: > > https://review.openstack.org/#/q/status:open+project:openstack/glance_store+branch:stable/kilo,n,z > > As Alan blocked them all, I’d like to ask

[openstack-dev] [stable][kilo] Call for testing: 2015.1.1 candidate tarballs

2015-07-09 Thread Alan Pevec
Hi all, We are scheduled to publish 2015.1.1 Kilo point releases, on Thursday July 16th for Ceilometer, Cinder, Glance, Heat, Horizon, Ironic, Keystone, Neutron, Nova, Sahara and Trove. We'd appreciate anyone who could test the candidate 2015.1.1 tarballs, which include all changes aside from any

Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job

2015-07-02 Thread Alan Pevec
> I could not reproduce on a clean centos7, so I'd like to grab nodepool > image to have a closer look After having a closer look, I see that image has requests 2.7 installed from pypi which overwrites python-requests RPM installation and wreaks havoc when trying to upgrade RPM. I'm not sure why a

Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job

2015-07-02 Thread Alan Pevec
2015-07-02 5:00 GMT+02:00 Ian Wienand : > So I looked into this with Gilles, and that error is a red-herring > (it's just saying the rdo repos don't create the presto/deltarpm > stuff); yep > the real issue is when python-requests fails to install [1] a > bit later due to [2] (mentioned in commen

Re: [openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

2015-06-17 Thread Alan Pevec
> http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz copy-paste fail, this should be: http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz __ OpenStack Development Mailing List (not for usage qu

[openstack-dev] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

2015-06-17 Thread Alan Pevec
Hi all, We are scheduled to publish 2014.1.5, last Icehouse point release, on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon, Keystone, Neutron, Nova and Trove. The list of issues fixed can be seen here: https://launchpad.net/ceilometer/+milestone/2014.1.5 https://launchpad.ne

Re: [openstack-dev] Targeting icehouse-eol?

2015-06-16 Thread Alan Pevec
> let's release this last one (codename: Farewell ?) point release. I > can do this next week after we finish pending reviews. Remaining stable/icehouse reviews[1] have -2 or -1 except https://review.openstack.org/176019 which I've asked neutron-stable-maint to review. Matt, anything else before w

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-15 Thread Alan Pevec
> The only issue is having a correct version number. Swift could well > iterate after "20151", for example doing "20151.1" then "20151.2", etc. Swift never had "coordinated" YEAR.N versions, https://wiki.openstack.org/wiki/Swift/version_map and they never released a version from their stable/* bra

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
> How do you check if project X in version n works with project Y in > version m, using this non-scheduled point release "free for all" model? That was an illusion of point releases, as Thierry said there wasn't significantly more testing and I don't remember any testing reports during stable free

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
>> and *Plan D* would be to start doing automatic per-project >> micro-versions on each commit: e.g. 2015.1.N where N is increased on >> each commit. > > How do you gpg sign these tags? I hope the solution isn't to store a key > in infra without a passphrase. Plan D doesn't include git tags, 2015.

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-07 Thread Alan Pevec
2015-06-06 19:08 GMT+02:00 Ian Cordasco : > Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid > SemVer (http://semver.org/) Right, so semver compatible versioning on stable/kilo would be 2015.1.N but PBR doesn't support that. > If we want to be pedantic about the version number

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-06 Thread Alan Pevec
2015-06-05 15:16 GMT+02:00 Jeremy Stanley : > On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote: > [...] >> I was wondering if we could switch to post-versioning on stable >> branches, and basically generate: >> >> "2015.1.0.post38" > [...] > > I think the recommendation from the PyPI main

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-06 Thread Alan Pevec
> Finally, I don't think this is still costly in terms of herding cats, > because we have very few cats actually grazing in the stable branch > pastures. I suggest that stable branch maintainers simply get used to > releasing on a weekly basis if there are new commits, and use that as > an opportun

Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)

2015-06-05 Thread Alan Pevec
> Why do we even drop stable branches? If anything, it introduces > unneeded problems to those who have their scripts/cookbooks set to > chase those branches. They would need to switch to eol tag. Because they would otherwise expect updates which will never come. They should take a notice and remo

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-05 Thread Alan Pevec
> If the downsteam consumer has their own extra patches ontop of the > stable branch, then it seems D is even less useful than A. It is not - downstream (speaking for RDO) I would keep Version: 2015.1.N where N is stable patch# so that we have a common reference point with other distros. Our patch

Re: [openstack-dev] Targeting icehouse-eol?

2015-06-04 Thread Alan Pevec
>>> The only open question I have is if we need to do an Icehouse point release >>> prior to the tag and dropping the branch, but I don't think that's happened >>> in the past with branch end of life - the eol tag basically serves as the >>> placeholder to the last 'release'. >> >> I don't think we

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
> *Plan C* would be to just let projects tag stable point releases from > time to time. That would solve all the original stated problems. And > that would solve objections 2 and 3, which I think are the most valid ones. and *Plan D* would be to start doing automatic per-project micro-versions on

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
>> One issue is how would we provide source tarballs, statically hosting >> tarballs for each and every micro version is not realistic, also those >> wouldn't be signed. > > Sorry, but why isn't it realistic, and why wouldn't they be signed? I thought storage requirements to generate tarball for e

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-06-01 Thread Alan Pevec
> You will get different checksums with tar and/or gzip, you can check the > extracted files and they should be the same. Yes, content is the same, it's just difference in timestamps of folders and generated files (ChangeLog, egg-info etc). > I would like to see signed commits in the 'official' r

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

2015-05-31 Thread Alan Pevec
2015-05-29 18:30 GMT+02:00 Jeremy Stanley : > On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote: >> This is generally my opinion as-well, I always hoped that *every* >> commit would be considered a release rather than an arbitrary >> tagged date. > [...] > > If we switch away from lockstep ma

Re: [openstack-dev] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0

2015-04-26 Thread Alan Pevec
> This is a problem of dependency resolution rather than an issue of > keystoneclient specifically. You can see that glanceclient has a cap on > keystoneclient that the installed version doesn't meet. python-keystoneclient>=1.1.0,<1.4.0 is requirement on python-glanceclient stable/kilo branch, w

Re: [openstack-dev] [swift] swift memory usage in centos7 devstack jobs

2015-03-27 Thread Alan Pevec
> I'll spend a bit more time on this -- I haven't determined if it's > centos or swift specific yet -- but in the mean-time, beware of > recent pyOpenSSL But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu? Alan _

Re: [openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2015-03-27 Thread Alan Pevec
> I'm working on removing mox in favor of mox3 to reduce a bit our dependency. Then mox3 should be imported to openstack namespace as suggested by Chuck in Dec 2013. Looks like last known source repository is https://github.com/emonty/pymox with last commit from Aug 2013 or did it move somewhere e

[openstack-dev] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

2015-03-26 Thread Alan Pevec
blast from the past... 2013-12-04 19:17 GMT+01:00 Chuck Short : > On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov wrote: ... >> 1) Figure out what is the deal with mox3 and decide if owning it will >> really be less trouble than porting nova. To be hones - I was unable to >> even find the code re

[openstack-dev] [oslo] oslo.concurrency runtime dependency on fixtures/testtools

2015-03-12 Thread Alan Pevec
Hi, hijacking this thread to point out something that feels wrong in the dependency chain which jumped out: > Colecting testtools>=0.9.22 (from > fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395) fixtures is imported in oslo_concurrency/fixture/lockutils.py but that's not real

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

2015-03-11 Thread Alan Pevec
> So, we can work around this in devstack, but it seems like there is a > more fundamental bug here that setup project isn't following dependencies. Dep chain was: testtools (from zake>=0.1->tooz<=0.12,>=0.3->ceilometer==2014.2.3.dev2) Unneeded _runtime_ dependency on testtools was removed in http

[openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions

2015-03-11 Thread Alan Pevec
Hi, next Icehouse stable point release 2014.1.4 has been slipping last few weeks due to various gate issues, see "Recently closed" section in https://etherpad.openstack.org/p/stable-tracker for details. Branch looks good enough now to push the release tomorrow (Thursdays are traditional release da

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

2015-03-10 Thread Alan Pevec
> The wheel has been removed from PyPI and anyone installing testtools > 1.7.0 now will install from source which works fine. On stable/icehouse devstack fails[*] with pkg_resources.VersionConflict: (unittest2 0.5.1 (/usr/lib/python2.7/dist-packages), Requirement.parse('unittest2>=1.0.0')) when in

Re: [openstack-dev] [neutron] New version of python-neutronclient release: 2.3.11

2015-02-20 Thread Alan Pevec
>> https://review.openstack.org/#/c/157535/ > > Do you know where it ends ? We could set up Depends lines on those > requirements stable/* reviews and line them up so that they are ready to > merge when openstackclient is fixed in devstack. Alternative workaround is https://review.openstack.org/15

Re: [openstack-dev] [neutron] New version of python-neutronclient release: 2.3.11

2015-02-20 Thread Alan Pevec
> (I believe the version cap for icehouse <2.4 is expected to a policy like > this). Yes, that assumed Semantic Versioning (semver.org) which 2.3.11 broke. Cheers, Alan __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

2015-02-12 Thread Alan Pevec
>> I think there's a place for >> private conversation (eg. discussing a security issue that corresponds >> to a CVE... > CVE's are a special exception and I'd even argue on the need of > private conversations there. Discussing CVEs in private came up few times but I'm not sure IRC is secure enou

Re: [openstack-dev] [stable] juno is fubar in the gate

2015-02-09 Thread Alan Pevec
>> >> Tracking etherpad: >> >> https://etherpad.openstack.org/p/wedged-stable-gate-feb-2015 BTW there is a tracking etherpad updated by https://wiki.openstack.org/wiki/StableBranch#Stable_branch_champions https://etherpad.openstack.org/p/stable-tracker linked in https://wiki.openstack.org/wiki/Sta

Re: [openstack-dev] django-openstack-auth and stable/icehouse

2015-02-04 Thread Alan Pevec
>> Dependencies in requirements.txt do not seem to be used in >> stable/icehouse gate jobs, recent pip freeze in stable/icehouse >> shows: ... oslo.config==1.6.0 # git sha 99e530e >> django-openstack-auth==1.1.9 # git sha 2079383 > > It's because of this: > > 2015-01-27 19:33:44.152 | Collecting os

Re: [openstack-dev] django-openstack-auth and stable/icehouse

2015-02-04 Thread Alan Pevec
> Bumping minimal oslo.config version due to the issue in > django-openstack-auth seems like a wrong way to do it. Dependencies in requirements.txt do not seem to be used in stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows: ... oslo.config==1.6.0 # git sha 99e530e django-ope

Re: [openstack-dev] [Nova] Requirements.txt and optional requirements

2015-01-30 Thread Alan Pevec
> - Remove this requirement, no optional entries in requirements.txt, a > 'deployer' has to know what dependencies the components he wants to use have Keystone is documenting its optional dependencies in test-requirements.txt look for # Optional ... comments in http://git.openstack.org/cgit/openst

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

2015-01-30 Thread Alan Pevec
2015-01-29 19:31 GMT+01:00 Joe Gordon : > That means clients need overlapping dependencies with the stable branches. > I don't think this is a reasonable requirement, and am not sure what we gain > from it. Capping all Oslo and clients on stable/juno was reverted[1] due to issue with upgrades whe

[openstack-dev] [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

2015-01-19 Thread Alan Pevec
> - periodic-nova-docs-icehouse > http://logs.openstack.org/periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ > : FAILURE in 1m 15s Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161 which is marked as Fix released, could infra team check if all images are alright? This showe

Re: [openstack-dev] [stable] Proposal to add Flavio Percoco to stable-maint-core

2015-01-07 Thread Alan Pevec
+2 Flavio knows stable branch policies very well and will be a good addition to the cross-projects stable team. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d

  1   2   >