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.
>>
>>
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
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
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
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
> 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
> 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
___
> 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
> 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
___
> 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/
> 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
___
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 (
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
> 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
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
__
> 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
+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
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
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
> 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
>> ^ ... --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
> 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
> 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,
>> 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
> 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
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
> 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
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,
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
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,
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
> 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
> 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
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
>>> 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
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
> 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 :)
> 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
> 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
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
> 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
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
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
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
> 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
> 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
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
>> 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
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,
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
> 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
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
__
>> [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
> 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
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_
> 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
>> 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
>> > > > 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
>> > >
...
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
@@
> 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
> 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
> 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,
> 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
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
> 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
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
> 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
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
> 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
> 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
> 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
>> 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.
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
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
> 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
> 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
> 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
>>> 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
> *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
>> 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
> 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
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
> 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
> 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
_
> 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
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
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
> 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
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
> 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
>> 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
> (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
>> 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
>> >> 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
>> 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
> 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
> - 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
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
> - 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
+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 - 100 of 170 matches
Mail list logo
