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

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

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

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

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)

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

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

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 [*]

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

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

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

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

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

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

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

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.

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:

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

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

[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

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

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

2016-03-16 Thread Alan Pevec
2016-03-16 11:23 GMT+01:00 Lukas Bezdicka <lbezd...@redhat.com>: >> ... >> - 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 ove

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

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?

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

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

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

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

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

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

[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

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

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

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

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

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 <z...@debian.org>: > On 12/16/2014 11:59 AM, Alan Pevec wrote: ... >> Current implementation in oslo service sends notification only just >> before e

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

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

[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

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

[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

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 that

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 of `git tag` unusable to

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

2015-07-30 Thread Alan Pevec
070b51603879f0f70f85f72e9e82126d1bb398ba Bump stable/kilo next version to 2015.1.2 2015.1.2.dev1 ** review 205130 rebased on top of 070b516 Bump... 2015.1.2.dev2 * post-version i.e. version = line removed from setup.cfg on top of 070b516 Bump... commit fb9582acc739d7719da0f1cc5f29b9e24097e025 Author: Alan

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 that

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

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

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 iwien...@redhat.com: 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]

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

[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

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

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 we

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/* branches.

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 ian.corda...@rackspace.com: 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

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.1.N

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 freeze

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

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 need to do a

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'

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 each

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-05-31 Thread Alan Pevec
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org: 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

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

2015-04-27 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, while

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

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

[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 chuck.sh...@canonical.com: On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov ndipa...@redhat.com 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 -

[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

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

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

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

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

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

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

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

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

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 joe.gord...@gmail.com: 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

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

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

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

2014-12-16 Thread Alan Pevec
2014-12-15 17:00 GMT+01:00 Clint Byrum cl...@fewbar.com: Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800: I guess Type=notify is supposed to be used with daemons that use Service class from oslo-incubator that provides systemd notification mechanism, or call to

[openstack-dev] [stable] Re: Stable check of openstack/cinder failed

2014-12-06 Thread Alan Pevec
2014-12-06 7:14 GMT+01:00 A mailing list for the OpenStack Stable Branch test reports. openstack-stable-ma...@lists.openstack.org: Build failed. - periodic-cinder-python26-icehouse http://logs.openstack.org/periodic-stable/periodic-cinder-python26-icehouse/d19db38 : FAILURE in 6m 50s -

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-04 Thread Alan Pevec
2014-12-03 22:10 GMT+01:00 Ben Nemec openst...@nemebean.com: On 12/03/2014 02:45 PM, Sean Dague wrote: So this - https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586 was clearly a violation of our 1 cycle for deprecation of config options. I think that

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-04 Thread Alan Pevec
I'd like to request another exception for Neutron to avoid introducing regression in hostname validation for DNS nameservers: https://review.openstack.org/#/c/139061/ Nice solution for this regression, I think it's worthy last-minute exception. Should VMT also send this officially to the

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

2014-12-04 Thread Alan Pevec
2014-12-04 23:00 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net: Finally was able to get the master version through the gate and cherry-picked it here: https://review.openstack.org/#/c/139194/ That one has made it through the check. So, if it isn't too late, it could use a +2/+A.

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

2014-12-04 Thread Alan Pevec
Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085 Since this is blocking stable/juno I've pushed partial revert of Revert Cap Oslo and client library versions https://review.openstack.org/138963 as a quickfix before the 2014.2.1 release today. We'll of course need to revisit

  1   2   >