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

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

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

> 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

> 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

> 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

> 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

> 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

> 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] [release] RDO Newton packages released

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

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

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

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

> 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

+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

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

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

> 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

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

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

> 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

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

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

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

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

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

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

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

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?

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

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

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

> 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

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.

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

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

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

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

[Openstack] [release] RDO Liberty released in CentOS Cloud SIG

in IRC #rdo channel ! Thanks, Alan Pevec Cloud SIG and RDO project member ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman

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

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?

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

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

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

> 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

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

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

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

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

[openstack-announce] OpenStack 2015.1.1 released

Hello everyone, The OpenStack Stable Maintenance team is happy to announce the release of the 2015.1.1 stable Kilo release. We have been busy reviewing and accepting backported bugfixes to the stable/kilo branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A

Re: [OpenStack-Infra] [openstack-dev] [all][infra] CI System is broken

2015-07-30 10:19 GMT+02:00 Andreas Jaeger a...@suse.com: It might be that some jobs from the last few hours were not enqueued and Zuul might have lost the events, It seems tag events for 2015.1.1 in neutron-*aas were lost, I pushed them around midnight GMT July 31:

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

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

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

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

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

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

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] CenOS7 kilo cannot find service type cloudformation when create heat endpoint .

today when I create heat_cfn endpoint: openstack endpoint create \ --publicurl http://controller:8000/v1 \ --internalurl http://controller:8000/v1 \ --adminurl http://controller:8000/v1 \ --region RegionOne \ cloudformation I encontered the following errer message: ERROR:

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

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

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-announce] OpenStack 2014.1.5 released

Hello everyone, The OpenStack Stable Maintenance team is eager to announce the release of the 2014.1.5 stable Icehouse. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A

[Openstack] OpenStack 2014.1.5 released

Hello everyone, The OpenStack Stable Maintenance team is eager to announce the release of the 2014.1.5 stable Icehouse. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A

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

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] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

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 ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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

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

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?

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

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

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

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

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?

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

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

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

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

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?

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

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?

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] OpenStack 2014.1.4 released

Hello everyone, The OpenStack Stable Maintenance team is happy to announce the 2014.1.4 stable Icehouse release. We have been busy reviewing and accepting backported bugfixes to the stable/icehouse branches according to the criteria set at: https://wiki.openstack.org/wiki/StableBranch A total

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

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

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

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

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

(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

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

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

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

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

  1   2   >