Re: [openstack-dev] [os-upstream-institute] Find a slot for a meeting to discuss - ACTION NEEDED

On Sat, Sep 29, 2018 at 02:50:31PM +0200, Ildiko Vancsa wrote: > Hi Training Team, > > Based on the votes on the Doodle poll below we will have our ad-hoc meeting > __next Friday (October 5) 1600 UTC__. > > Hangouts link for the call: > https://hangouts.google.com/call/BKnvu7e72uB_Z-QDHDF2AAEI

Re: [openstack-dev] [sahara] PTL out for a week

Enjoy the PTO, Telles! I don't really have much to share at a meeting. My vote is for no meeting. Our other active core and other active community members can agree to cancel or not, and I'll heed that decision. On Wed, Oct 10, 2018 at 4:42 PM Telles Nobrega wrote: > Hi all, > > I'm taking PTO

[openstack-dev] [Searchlight] Team meeting today at 1200

Hi team, This is just a reminder that we will have a team meeting at 12:00 UTC today on #openstack-meeting-4 Bests, -- *Trinh Nguyen* *www.edlab.xyz * __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [all] Stepping down from Release Management team

> On Oct 8, 2018, at 2:34 PM, Doug Hellmann wrote: > > Anne Bertucio writes: > >> Hi all, >> >> I have had a fantastic time getting to work on the Release Management >> team and getting to know you all through the release marketing work, >> however, it is time for me to step down from my

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 2018-10-10 16:35:38 -0700 (-0700), Goutham Pacha Ravi wrote: [...] > Thanks Corey for starting this effort. I proposed changes to > manila repos to use your template [1] [2], but the interpreter's > not being installed, do you need to make any bindep changes to > enable the "universe" ppa and

Re: [openstack-dev] [python3] Enabling py37 unit tests

On Wed, Oct 10, 2018 at 2:10 PM Jeremy Stanley wrote: > > On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote: > [...] > > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and > > 3.7. > [...] > > I might have only pointed this out on IRC so far, but the > expectation is that

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 2018-10-10 16:00:40 -0500 (-0500), Sean McGinnis wrote: [...] > I would rather see us testing 3.5 and 3.7 versus 3.5, 3.6, and > 3.7. [...] I might have only pointed this out on IRC so far, but the expectation is that testing 3.5 and 3.6 at the same time was merely transitional since official

Re: [openstack-dev] [python3] Enabling py37 unit tests

> > > > > > What I mean is that we run too into a situation where we have a large > > backlog of CI jobs since we have to many changes and jobs in flight. > > > > So, I'm asking whether there is a good way to not duplicating all jobs > > to run on all three interpreters. Do we really need testing

[openstack-dev] [sahara] PTL out for a week

Hi all, I'm taking PTO from tomorrow until Monday Oct 22nd. I won't cancel the meeting yet but let me know if you want me to. See you all in a couple weeks. Thanks, -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil Av. Brg. Faria Lima, 3900 - 8º andar - Itaim

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On 10/10/18 1:35 PM, Greg Hill wrote: I'm not sure how using pull requests instead of Gerrit changesets would help "core reviewers being pulled on to other projects"? The 2 +2 requirement works for larger projects with a lot of contributors. When you have only 3 regular

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On 10/10/2018 12:41 PM, Greg Hill wrote: > I've been out of the openstack loop for a few years, so I hope this > reaches the right folks. > > Josh Harlow (original author of taskflow and related libraries) and I > have been discussing the option of moving taskflow out of the openstack >

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On 10.10.2018 09:06, Florian Engelmann wrote: Now I get you. I would say all configuration templates need to be changed to allow, eg. $ grep http /etc/kolla/cinder-volume/cinder.conf glance_api_servers = http://10.10.10.5:9292 auth_url = http://internal.somedomain.tld:35357

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On 2018-10-10 13:35:00 -0500 (-0500), Greg Hill wrote: [...] > We plan to still have a CI gatekeeper, probably Travis CI, to make sure PRs > past muster before being merged, so it's not like we're wanting to > circumvent good contribution practices by committing whatever to HEAD. Travis CI has

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On Wed, Oct 10, 2018, at 11:35 AM, Greg Hill wrote: > > I'm not sure how using pull requests instead of Gerrit changesets would > > help "core reviewers being pulled on to other projects"? > > > > The 2 +2 requirement works for larger projects with a lot of contributors. > When you have only 3

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On Wed, Oct 10, 2018 at 2:35 PM Greg Hill wrote: > > I'm not sure how using pull requests instead of Gerrit changesets would >> help "core reviewers being pulled on to other projects"? >> > > The 2 +2 requirement works for larger projects with a lot of contributors. > When you have only 3

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

> I'm not sure how using pull requests instead of Gerrit changesets would > help "core reviewers being pulled on to other projects"? > The 2 +2 requirement works for larger projects with a lot of contributors. When you have only 3 regular contributors and 1 of them gets pulled on to a project and

Re: [openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

On 10/10/2018 01:41 PM, Greg Hill wrote: I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella

[openstack-dev] [oslo][taskflow] Thoughts on moving taskflow out of openstack/oslo

I've been out of the openstack loop for a few years, so I hope this reaches the right folks. Josh Harlow (original author of taskflow and related libraries) and I have been discussing the option of moving taskflow out of the openstack umbrella recently. This move would likely also include the

Re: [openstack-dev] [kolla][tc] add service discovery, proxysql, vault, fabio and FQDN endpoints

+tc topic On 10/10/2018 11:49 AM, Fox, Kevin M wrote: Sorry. Couldn't quite think of the name. I was meaning, openstack project tags. I think having a tag that indicates the project is no longer using SELECT FOR UPDATE (and thus is safe to use multi-writer Galera) is an excellent idea,

Re: [openstack-dev] [Openstack-operators] [nova] Supporting force live-migrate and force evacuate with nested allocations

>> I disagree on this. I'd rather just do a simple check for >1 >> provider in the allocations on the source and if True, fail hard. >> >> The reverse (going from a non-nested source to a nested destination) >> will hard fail anyway on the destination because the POST >> /allocations won't work

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

Sorry. Couldn't quite think of the name. I was meaning, openstack project tags. Thanks, Kevin From: Jay Pipes [jaypi...@gmail.com] Sent: Tuesday, October 09, 2018 12:22 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [kolla] add

[openstack-dev] [puppet][tripleo][all] Zuul job backlog

Wesley Hayutin writes: [snip] The TripleO project has created a single node container based composable OpenStack deployment [2]. It is the projects intention to replace most of the TripleO upstream jobs with the Standalone deployment. We would like to reduce our multi-node usage to a total

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

Hi Won, On Wed, Oct 10, 2018 at 11:58 AM Won wrote: > > my prometheus version : 2.3.2 and alertmanager version : 0.15.2 and I > attached files.(vitrage collector,graph logs and apache log and > prometheus.yml alertmanager.yml alarm rule file etc..) > I think the problem that resolved alarm does

Re: [openstack-dev] [python3] Enabling py37 unit tests

On Wed, Oct 10, 2018 at 10:18 AM Jeremy Stanley wrote: > On 2018-10-10 16:09:21 +0200 (+0200), Andreas Jaeger wrote: > [...] > > So, I'm asking whether there is a good way to not duplicating all > > jobs to run on all three interpreters. Do we really need testing > > of all three versions? Or is

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 2018-10-10 16:09:21 +0200 (+0200), Andreas Jaeger wrote: [...] > So, I'm asking whether there is a good way to not duplicating all > jobs to run on all three interpreters. Do we really need testing > of all three versions? Or is testing with a subset a manageable > risk? OpenStack projects are

Re: [openstack-dev] [python3] Enabling py37 unit tests

On Wed, Oct 10, 2018 at 10:09 AM Andreas Jaeger wrote: > On 10/10/2018 15.42, Corey Bryant wrote: > > > > > > On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger > > wrote: > > > > On 10/10/2018 14.45, Corey Bryant wrote: > > > [...] > > > == Enabling py37 unit

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/10/2018 7:46 AM, Jay Pipes wrote: 2) in the old microversions change the blind allocation copy to gather every resource from a nested source RPs too and try to allocate that from the destination root RP. In nested allocation cases putting this allocation to placement will fail and nova

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 10/10/2018 15.42, Corey Bryant wrote: On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger > wrote: On 10/10/2018 14.45, Corey Bryant wrote: > [...] > == Enabling py37 unit tests == > > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/9/2018 10:08 AM, Balázs Gibizer wrote: Question for you as well: if we remove (or change) the force flag in a new microversion then how should the old microversions behave when nested allocations would be required? Fail fast if we can detect we have nested. We don't support forcing

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 10/10/2018 09:42 AM, Corey Bryant wrote: On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger > wrote: On 10/10/2018 14.45, Corey Bryant wrote: > [...] > == Enabling py37 unit tests == > > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 2018-10-10 09:38:14 -0400 (-0400), Corey Bryant wrote: [...] > Another option could be to use a non-LTS image to use a supported > release. Let's avoid creating additional images unless there is a strong reason (every additional image means more load on our image builders, more space consumed

Re: [openstack-dev] [python3] Enabling py37 unit tests

On Wed, Oct 10, 2018 at 9:26 AM Andreas Jaeger wrote: > On 10/10/2018 14.45, Corey Bryant wrote: > > [...] > > == Enabling py37 unit tests == > > > > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews > > up to define the py37 zuul job and templates here: > >

Re: [openstack-dev] [python3] Enabling py37 unit tests

On Wed, Oct 10, 2018 at 9:27 AM Jeremy Stanley wrote: > On 2018-10-10 08:45:39 -0400 (-0400), Corey Bryant wrote: > [...] > > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter > [...] > > Thanks for the heads up! Last time I looked it was still a pre-3.7.0 > beta package, but looks like that

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 10/10/2018 14.45, Corey Bryant wrote: [...] == Enabling py37 unit tests == Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter and I have reviews up to define the py37 zuul job and templates here: https://review.openstack.org/#/c/609066 I'd like to start submitting reviews to projects to

Re: [openstack-dev] [python3] Enabling py37 unit tests

On 2018-10-10 08:45:39 -0400 (-0400), Corey Bryant wrote: [...] > Ubuntu Bionic (18.04 LTS) has the 3.7.0 interpreter [...] Thanks for the heads up! Last time I looked it was still a pre-3.7.0 beta package, but looks like that has finally been updated to a proper release of the interpreter for

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

On 2018-10-10 13:24:28 +1100 (+1100), Gilles Dubreuil wrote: > On 09/10/18 23:58, Jeremy Stanley wrote: > > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote: > > [...] > > > It seems to me that a major goal of openstacksdk is to hide > > > differences between clouds from the user. If

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On Wed, Oct 10, 2018 at 2:46 PM, Jay Pipes wrote: > On 10/10/2018 06:32 AM, Balázs Gibizer wrote: >> Hi, >> >> Thanks for all the feedback. I feel the following consensus is >> forming: >> >> 1) remove the force flag in a new microversion. I've proposed a spec >> about that API change [1] >

Re: [openstack-dev] [api] Open API 3.0 for OpenStack API

On Tue, Oct 9, 2018 at 10:25 PM Gilles Dubreuil wrote: > > > On 09/10/18 23:58, Jeremy Stanley wrote: > > On 2018-10-09 08:52:52 -0400 (-0400), Jim Rollenhagen wrote: > > [...] > >> It seems to me that a major goal of openstacksdk is to hide differences > >> between clouds from the user. If the

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/10/2018 06:32 AM, Balázs Gibizer wrote: Hi, Thanks for all the feedback. I feel the following consensus is forming: 1) remove the force flag in a new microversion. I've proposed a spec about that API change [1] +1 2) in the old microversions change the blind allocation copy to gather

[openstack-dev] [python3] Enabling py37 unit tests

Hi All, I'd like to enable py37 unit tests in the gate. == Background == I work on OpenStack packaging for Ubuntu. During the Rocky release (Ubuntu Cosmic) I tried to fix py37 bugs upstream as I came across them. There ended up being a lot of py37 issues and after a while, due to time

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On 10/09/2018 05:01 PM, Eric Fried wrote: On 10/09/2018 02:20 PM, Jay Pipes wrote: On 10/09/2018 11:04 AM, Balázs Gibizer wrote: If you do the force flag removal in a nw microversion that also means (at least to me) that you should not change the behavior of the force flag in the old

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Le mer. 10 oct. 2018 à 12:32, Balázs Gibizer a écrit : > Hi, > > Thanks for all the feedback. I feel the following consensus is forming: > > 1) remove the force flag in a new microversion. I've proposed a spec > about that API change [1] > > Thanks, will look at it. > 2) in the old

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Hi, Thanks for all the feedback. I feel the following consensus is forming: 1) remove the force flag in a new microversion. I've proposed a spec about that API change [1] 2) in the old microversions change the blind allocation copy to gather every resource from a nested source RPs too and try

Re: [openstack-dev] [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit admin approve the remaining zuul job settings import patches

No objections from me for monasca-analytics repo. Witek > -Original Message- > From: Doug Hellmann > Sent: Montag, 8. Oktober 2018 17:08 > To: openstack-dev > Subject: [openstack-dev] > [goals][python3][telemetry][barbican][monasca][neutron] having a gerrit > admin approve the

Re: [openstack-dev] [watcher] [monasca] Bare metal node N+1 redundancy and Proactive HA

Hi Alex, Have a nice day. Regarding to "Proactive HA", we decided to follow 3 steps: 1. Test Live Migration feature of Watcher (done for basic test) Thanks to your great help via Watcher IRC channel, I have configured Live Migration successfully. I have already performed several tests for "Host

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

On Tue, Oct 9, 2018 at 11:01 PM, Eric Fried wrote: > > > On 10/09/2018 02:20 PM, Jay Pipes wrote: >> On 10/09/2018 11:04 AM, Balázs Gibizer wrote: >>> If you do the force flag removal in a nw microversion that also >>> means >>> (at least to me) that you should not change the behavior of

[openstack-dev] [watcher] [monasca] Bare metal node N+1 redundancy and Proactive HA

Greetings Fujitsu team, During last PTG we've discussed two new blueprints[1] and how they can be implemented on Watcher and Monasca sides. What is the status of these BPs? Do you need my help with it? Witek, should we submit these BPs on Monasca's Storyboard? [1]:

Re: [openstack-dev] [openstack-ansible] dropping xenial jobs

On 10/10/18, 5:54 AM, "Mohammed Naser" wrote: >So I’ve been thinking of dropping the Xenial jobs to reduce our overall > impact in terms of gate usage in master because we don’t support it. I think we can start dropping it given our intended supported platform for Stein is Bionic, not

Re: [openstack-dev] [tc] assigning new liaisons to projects

On Mon, 2018-10-08 at 10:27 -0400, Doug Hellmann wrote: > TC members, > > Since we are starting a new term, and have several new members, we > need > to decide how we want to rotate the liaisons attached to each our > project teams, SIGs, and working groups [1]. > > Last term we went through a

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

On Wed, 10 Oct 2018 at 08:08, Florian Engelmann < florian.engelm...@everyware.ch> wrote: > Am 10/9/18 um 1:47 PM schrieb Mark Goddard: > > > > > > On Tue, 9 Oct 2018 at 12:03, Florian Engelmann > > mailto:florian.engelm...@everyware.ch>> > > > wrote: > > > > Am 10/9/18 um 11:04 AM schrieb

Re: [openstack-dev] [openstack-ansible] dropping xenial jobs

On Wed, 2018-10-10 at 06:50 +0200, Mohammed Naser wrote: > Hi everyone! > > So I’ve been thinking of dropping the Xenial jobs to reduce our > overall impact in terms of gate usage in master because we don’t > support it. > > However, I was a bit torn on this because i realize that it’s >

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

by "another storage system" you mean the KV store of consul? That's just someting consul brings with it... consul is very strong in doing health checks Am 10/9/18 um 6:09 PM schrieb Fox, Kevin M: etcd is an already approved openstack dependency. Could that be used instead of consul so as to

Re: [openstack-dev] [kolla] add service discovery, proxysql, vault, fabio and FQDN endpoints

Am 10/9/18 um 1:47 PM schrieb Mark Goddard: On Tue, 9 Oct 2018 at 12:03, Florian Engelmann mailto:florian.engelm...@everyware.ch>> wrote: Am 10/9/18 um 11:04 AM schrieb Mark Goddard: > Thanks for these suggestions Florian, there are some interesting ideas > in here. I'm a

Re: [openstack-dev] [Cyborg] Core Team Update

Big +1, xinran has been tremendously helpful in the development. On Tue, Oct 9, 2018, 7:55 PM Li Liu wrote: > Hi Cyborg Team, > > I want to nominate Xinran Wang as a new core reviewer for Cyborg project. > Xiran has been working hard and kept contributing to the project[1][2]. > Keep Claim and