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

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

[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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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:

[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

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