Re: [openstack-dev] [ALL][requirements] A freeze is coming and you should be prepared

On 18-01-24 22:32:27, Matthew Thode wrote: > On 18-01-24 01:29:47, Matthew Thode wrote: > > On 18-01-23 01:23:50, Matthew Thode wrote: > > > Requirements is freezing Friday at 23:59:59 UTC so any last > > > global-requrements updates that need to get in need to get in now. > > > > > > I'm afraid

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

For my part, I tried it [1] and it doesn't seem to have worked. (The functional test failure is what the dep is supposed to have fixed.) Did I do something wrong? [1] https://review.openstack.org/#/c/533821/12 On 01/25/2018 09:33 PM, Mathieu Gagné wrote: > On Thu, Jan 25, 2018 at 7:08 PM,

Re: [openstack-dev] Swift-backed volume backups are still breaking the gate

On Thu, Jan 25, 2018 at 7:01 PM, Matt Riedemann wrote: > Is ThreadSafeSysLogHandler something that could live in oslo.log so we > don't have to whack this mole everywhere at random times? That might make sense, unless we can get eventlet's monkey patching of the logging

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On Thu, Jan 25, 2018 at 7:08 PM, James E. Blair wrote: > Mathieu Gagné writes: > >> On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: >>> >>> >>> I'm curious what this means as far as best practices for inter-patch >>> references.

Re: [openstack-dev] Swift-backed volume backups are still breaking the gate

On 1/25/2018 6:41 PM, Clay Gerrard wrote: Does it help that swift also had to fix this? https://github.com/openstack/swift/blob/6d2503652b5f666275113cf9f3e185a2d9b3a121/swift/common/utils.py#L4415 The interesting/useful bit is where we replace our primary loghandlers createLock method to use

Re: [openstack-dev] [tripleo] CI'ing ceph-ansible against TripleO scenarios

On Thu, Jan 25, 2018 at 04:22:56PM -0800, Emilien Macchi wrote: > Is there any plans to run TripleO CI jobs in ceph-ansible? > I know the project is on github but thanks to zuulv3 we can now easily > configure ceph-ansible to run Ci jobs in OpenStack Infra. > > It would be really great to

[openstack-dev] [release][ptl][all] please approve the reno updates for queens

As part of creating branches for projects, the job proposes updates to add a "queens" page to the release notes build. The script prepares a best-effort version of the update, but local variances in the repositories means that doesn't always work. Please take the patches over and fix them, then

Re: [openstack-dev] Swift-backed volume backups are still breaking the gate

Does it help that swift also had to fix this? https://github.com/openstack/swift/blob/6d2503652b5f666275113cf9f3e185a2d9b3a121/swift/common/utils.py#L4415 The interesting/useful bit is where we replace our primary loghandlers createLock method to use one of these [Green|OS]-thread-safe PipeMutex

[openstack-dev] [tripleo] CI'ing ceph-ansible against TripleO scenarios

Is there any plans to run TripleO CI jobs in ceph-ansible? I know the project is on github but thanks to zuulv3 we can now easily configure ceph-ansible to run Ci jobs in OpenStack Infra. It would be really great to investigate that in the near future so we avoid eventual regressions. Sebastien,

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

Mathieu Gagné writes: > On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: >> >> >> I'm curious what this means as far as best practices for inter-patch >> references. In the past my understanding was the the change id was >> preferred, both because

[openstack-dev] [nova] q-3 tag and gate status

At this point in the day, I'm going to push the q-3 tag. We have quite a few things approved but not yet merged (some for over 20 hours in the gate now). The latest list of stuff that's approved is in the etherpad here: https://etherpad.openstack.org/p/nova-queens-blueprint-status I don't

Re: [openstack-dev] [tripleo] branching stable/queens for tripleoclient

On Thu, Jan 25, 2018 at 10:59 AM, Emilien Macchi wrote: > Hi, > > We're about to release Queens milestone 3. > > https://review.openstack.org/537752 > > Which means, we'll branch tripleoclient stable/queens this week. > Since we don't follow stable policy anymore, we can in

Re: [openstack-dev] Issue with eventlet monkey patching

Thanks Slawek, this indeed looks like the problem we are having with Glance. Searchlight, too. On Thu, Jan 25, 2018 at 10:53 AM, Sławomir Kapłoński wrote: > Hi, > > Recently we found in Neutron errors with starting our agents which uses > eventlet.monkey_patch() method.

[openstack-dev] [cinder] Deprecation of Kaminario and Pure automatic calculation for max_over_subscription_ratio

Folks, In the Queens release, Cinder has implemented an internal mechanism to automatically calculate the max_over_subscription_ratio[1]. As Kaminario and Pure drivers already have a config option and are doing that internally, we kindly recommend that the driver maintainers deprecate those

Re: [openstack-dev] [keystone] FFE for application credentials

On Thu, Jan 25, 2018 at 4:24 PM, Colleen Murphy wrote: > +1 > +1 > On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad wrote: >> Hey all, >> >> The work for system assignments and system scope [0] has been up for a >> while, reviewers are happy with it,

Re: [openstack-dev] [keystone] FFE for unified limits

On Thu, Jan 25, 2018 at 4:17 PM, Colleen Murphy wrote: > +1 > +1 > On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad wrote: >> Hey all, >> >> The work for unified limits [0] has been up for a while, reviewers are >> happy with it being experimental, and

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On Thu, Jan 25, 2018 at 3:55 PM, Ben Nemec wrote: > > > I'm curious what this means as far as best practices for inter-patch > references. In the past my understanding was the the change id was > preferred, both because if gerrit changed its URL format the change id links

Re: [openstack-dev] [keystone] FFE for application credentials

+1 On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad wrote: > Hey all, > > The work for system assignments and system scope [0] has been up for a > while, reviewers are happy with it, and it is slowly making it's way > through the gate. I propose we consider a feature freeze

Re: [openstack-dev] [keystone] FFE for application credentials

+1 On Thu, Jan 25, 2018 at 10:15 PM, Lance Bragstad wrote: > Hey all, > > The work for application credentials [0] has been up for a while, > reviewers are happy with it, and it is slowly making it's way through > the gate. I propose we consider a feature freeze exception

Re: [openstack-dev] [keystone] FFE for unified limits

+1 On Thu, Jan 25, 2018 at 10:14 PM, Lance Bragstad wrote: > Hey all, > > The work for unified limits [0] has been up for a while, reviewers are > happy with it being experimental, and it is slowly making it's way > through the gate. I propose we consider a feature freeze

Re: [openstack-dev] [keystone] FFE for application credentials

The subject of this message should have been "FFE for system scope"... not application credentials. Apologies for the confusion. On 01/25/2018 03:15 PM, Lance Bragstad wrote: > Hey all, > > The work for system assignments and system scope [0] has been up for a > while, reviewers are happy with

[openstack-dev] [keystone] FFE for application credentials

Hey all, The work for system assignments and system scope [0] has been up for a while, reviewers are happy with it, and it is slowly making it's way through the gate. I propose we consider a feature freeze exception given the state of the gate and the frequency of rechecks/failures. Thoughts,

[openstack-dev] [keystone] FFE for unified limits

Hey all, The work for unified limits [0] has been up for a while, reviewers are happy with it being experimental, and it is slowly making it's way through the gate. I propose we consider a feature freeze exception given the state of the gate and the frequency of rechecks/failures. Thoughts,

[openstack-dev] [keystone] FFE for application credentials

Hey all, The work for application credentials [0] has been up for a while, reviewers are happy with it, and it is slowly making it's way through the gate. I propose we consider a feature freeze exception given the state of the gate and the frequency of rechecks/failures. Thoughts, comments, or

[openstack-dev] Swift-backed volume backups are still breaking the gate

We thought things were fixed with [1] but it turns out that swiftclient logs requests and responses at DEBUG level, so we're still switching thread context during a backup write and failing the backup operation, causing copious amounts of pain in the gate and piling up the rechecks. I've got

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

On 01/24/2018 02:31 PM, Monty Taylor wrote: On 01/24/2018 02:25 PM, David Shrewsbury wrote: This is a (the?) killer feature. On Wed, Jan 24, 2018 at 11:33 AM, James E. Blair > wrote:     Hi,     We recently introduced a new URL-based

[openstack-dev] [tripleo] branching stable/queens for tripleoclient

Hi, We're about to release Queens milestone 3. https://review.openstack.org/537752 Which means, we'll branch tripleoclient stable/queens this week. Since we don't follow stable policy anymore, we can in theory accept any backport but I would ask our team to backport only bugfixes and things

[openstack-dev] [neutron][l3][flavors][floatingip] FFE request for patch no 523257 and 532993

Hello all ! I'd like to request a FFE for patch 523257 [1] that adds new resources and events to handle operations For routers if L3 flavors framework is used. The neutron-lib part is already merged [lib] thanks to Boden and Miguel for quick reviews on that. The second patch 53993 [2] adds the

[openstack-dev] [neutron][l3][flavors] FFE request for patch no 523257 and 532993

Hello all ! I'd like to request a FFE for patch 523257 [1] that adds new resources and events to handle operations For routers if L3 flavors framework is used. The neutron-lib part is already merged [lib] thanks to Boden and Miguel for quick reviews on that. The second patch 53993 [2] adds the

Re: [openstack-dev] [nova][thirdparty][CI] Nova IBM zKVM CI broken

CI should be back online now, tests are running again… Let’s see if the tests succeed.. The issue was, that for some reason a new pip package ‘python-pcre’ got installed. But the build failed, as the build dependency 'libpcre3-dev’ as not satisfied. Now the package 'libpcre3-dev' is part of

[openstack-dev] Issue with eventlet monkey patching

Hi, Recently we found in Neutron errors with starting our agents which uses eventlet.monkey_patch() method. Bug is described in [1]. I heard on IRC that it's not related only to Neutron so here is what we found about that. It looks that this issue happens on Ubuntu with python2.7

Re: [openstack-dev] [oslo][oslo.log] JSON logs are missing the request ID

Excerpts from Saverio Proto's message of 2018-01-24 22:18:39 +0100: > > 3.34.0 is a queens series release, which makes it more likely that more > > other dependencies would need to be updated. Even backporting the > > changes to the Ocata branch and releasing it from there would require > >

[openstack-dev] RHOSP 10 registering nodes for the undercloud fails

Hello, I am trying to deploy OpenStack 10 using OpenStack Platform Director 10. I am using a bare-metal server with RedHat 7.4, on which I have created 3 VMs: 1st VM is the undercloud node, 2nd VM is the overcloud controller node and the 3rd VM is the overcloud compute node. The bare-metal

[openstack-dev] (no subject)

osa...@gmail.com __ 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

[openstack-dev] [release] Release countdown for week R-4, January 27 - February 2

Happy deadline week everyone. Here's what's coming up for next week. Development Focus - The R-4 week is our one deadline free week between the lib freezes and Queens-3 milestone and RC. Work should be focused on fixing any requirements update issues, critical bugs, and wrapping

[openstack-dev] [vitrage] Vitrage templates are now loaded using a new API

Hi, A new API for Vitrage template add and template delete was added this week. As part of this change, Vitrage templates are now stored in a database and are no longer read from the file system. In case you are using templates, make sure to call the new API and add them to Vitrage once you

Re: [openstack-dev] [release][puppet] Tarballs missing for some puppet modules in pike

On Thu, Jan 25, 2018 at 10:49:10AM +0100, Alfredo Moralejo Alonso wrote: > Hi, > > We had the same issue again in release-post job for > https://review.openstack.org/#/c/536927/ > > Logs in >

[openstack-dev] [all][api] API-SIG meeting cancelled

Today's (25th January) API-SIG meeting has been cancelled. The usual chairs are either travelling or ill. Regular schedule will resume next week. -- Chris Dent (⊙＿⊙') https://anticdent.org/ freenode: cdent tw:

Re: [openstack-dev] [kuryr][libnetwork] Release kuryr-libnetwork 1.x for Queens

On Mon, Jan 22, 2018 at 3:46 PM, Daniel Mellado wrote: > +1 > > > El 21/1/18 a las 8:13, Irena Berezovsky escribió: > > +1 > > On Fri, Jan 19, 2018 at 9:42 PM, Hongbin Lu wrote: >> >> Hi Kuryr team, >> >> I think Kuryr-libnetwork is ready to move

Re: [openstack-dev] [requirements] [vitrage][glance] global requirements update for python-vitrageclient

Adding Glance team. Any idea what could be wrong? Thanks, Ifat. On 25/01/2018, 9:09, "Afek, Ifat (Nokia - IL/Kfar Sava)" wrote: Hi, I tried to update the version of python-vitrageclient [1], but the legacy-requirements-integration-dsvm test failed with an

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On 24 January 2018 at 22:57, Matt Riedemann wrote: > On 1/22/2018 8:22 AM, Lee Yarwood wrote: > >> Hello, >> >> With M3 and FF rapidly approaching this week I wanted to post a brief >> overview of the QEMU native LUKS series. >> >> The full series is available on the

Re: [openstack-dev] [nova] PTL Election Season

On Mon, Jan 22, 2018 at 05:09:31PM -0600, Matt Riedemann wrote: [...] > To anyone that cares, I don't plan on running for Nova PTL again for the > Rocky release. Queens was my fourth tour and it's definitely time for > someone else to get the opportunity to lead here. I don't plan on going >

[openstack-dev] [nova][thirdparty][CI] Nova IBM zKVM CI broken

Hi, the Nova IBM zKVM CI is currently producing invalid builds. Please ignore the -1 results for now. I’m working on fixing it. Will let you know once it’s working fine again. Thanks! --- Andreas Scheuring (andreas_s)

Re: [openstack-dev] [release][puppet] Tarballs missing for some puppet modules in pike

Hi, We had the same issue again in release-post job for https://review.openstack.org/#/c/536927/ Logs in http://logs.openstack.org/32/323c387a2d1794e0679510657629470da8f7de92/release-post/tag-releases/b2091f1/job-output.txt.gz shows a similar issue. The script stuck at doing a "git fetch" Best