[openstack-dev] DeployArtifacts considered...complicated?

I've been working on a series of patches to enable support for keystone federation in tripleo. I've been making good use of the DeployArtifacts support for testing puppet modules...until today. I have some patches that teach puppet-keystone about multi-valued configuration options (like

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

Excerpts from Eric Fried's message of 2018-06-15 18:09:49 -0500: > Doug- > > > The lower constraints tests only look at files in the same repo. > > The minimum versions of dependencies set in requirements.txt, > > test-requirements.txt, etc. need to match the values in > > lower-constraints.txt.

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

Doug- > The lower constraints tests only look at files in the same repo. > The minimum versions of dependencies set in requirements.txt, > test-requirements.txt, etc. need to match the values in > lower-constraints.txt. > > In this case, the more detailed error message is a few lines above the >

[openstack-dev] [neutron][api[[graphql] A starting point

Hello, This initial patch [1]  allows to retrieve networks, subnets. This is very easy, thanks to the graphene-sqlalchemy helper. The edges, nodes layer might be confusing at first meanwhile they make the Schema Relay-compliant in order to offer re-fetching, pagination features out of the

Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)

On Mon, Jun 4, 2018 at 6:26 PM, Emilien Macchi wrote: > TL;DR: we made nice progress and you can checkout this demo: > https://asciinema.org/a/185533 > > We started the discussion back in Dublin during the last PTG. The idea of > Standalone (aka All-In-One, but can be mistaken with all-in-one

Re: [openstack-dev] [nova] [placement] placement update 18-24

Thank you as always for doing this, Chris. > Some of the older items in this list are not getting much attention. > That's a shame. The list is ordered (oldest first) the way it is on > purpose. > > * >   Purge comp_node and res_prvdr records during

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Fri, Jun 15, 2018 at 2:13 AM Michele Baldessari wrote: > On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: > > During the Storyboard session today: > > https://etherpad.openstack.org/p/continuing-the-migration-lp-sb > > > > We mentioned that TripleO would continue to migrate

Re: [openstack-dev] [nova] Rocky blueprint status tracking

On 6/15/2018 11:23 AM, melanie witt wrote: Similar to last cycle, we have an etherpad for tracking the status of approved nova blueprints for Rocky here: https://etherpad.openstack.org/p/nova-rocky-blueprint-status that we can use to help us review patches. If I've missed any blueprints or

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

Excerpts from Jean-Philippe Evrard's message of 2018-06-15 17:37:02 +0200: > > Not sure it'd help but one option we do is to create aliases based on > > the title. Though since the PTLs don't have addresses on the openstack > > domain an alias may not make as much sense, it'd have to be a full >

Re: [openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Excerpts from corvus's message of 2018-06-15 08:46:40 -0700: > Doug Hellmann writes: > > > Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900: > > >> Yes, It will not be set on LIBS_FROM_GIT as we did not set it > >> explicitly. But gate running on any repo does run job on current >

[openstack-dev] [keystone] Keystone Team Update - Week of 11 June 2018

# Keystone Team Update - Week of 11 June 2018 ## News ### New Implied Roles in keystone-manage bootstrap We landed one of the first building blocks for Default Roles across OpenStack, which is ensuring they are created during the bootstrap of keystone[1]. Since this is new feature of the

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

> I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. > > I would really like NOT to see logic like this in any nova code: > >> if kvm|qemu: >> return 256 >> elif POWER: >> return 4000 >> elif: >>

[openstack-dev] [nova] Rocky blueprint status tracking

Howdy everyone, Similar to last cycle, we have an etherpad for tracking the status of approved nova blueprints for Rocky here: https://etherpad.openstack.org/p/nova-rocky-blueprint-status that we can use to help us review patches. If I've missed any blueprints or if anything needs an

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On Thu, Jun 14, 2018 at 11:03 PM Michele Baldessari wrote: > > +1 > > On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote: > > Alan Bishop has been highly involved in the Storage backends integration in > > TripleO and Puppet modules, always here to update with new features, fix >

Re: [openstack-dev] [neutron] Question on the OVS configuration

You are using vxlan network which is not going through br-ex but via br-tun. In br-tun You have established vxlan tunnel: >Port "vxlan-c0a81218" >Interface "vxlan-c0a81218" >type: vxlan >options: {df_default="true", in_key=flow, >

Re: [openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Doug Hellmann writes: > Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900: >> Yes, It will not be set on LIBS_FROM_GIT as we did not set it >> explicitly. But gate running on any repo does run job on current >> change set of that repo which is nothing but "master + current patch >>

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

> Not sure it'd help but one option we do is to create aliases based on > the title. Though since the PTLs don't have addresses on the openstack > domain an alias may not make as much sense, it'd have to be a full > account forward. It's useful for centralized spam filtering. I foresee this: 1)

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

On 18-06-15 15:29:07, Jeremy Stanley wrote: > On 2018-06-15 10:23:36 -0500 (-0500), Matthew Thode wrote: > [...] > > Not sure it'd help but one option we do is to create aliases based > > on the title. Though since the PTLs don't have addresses on the > > openstack domain an alias may not make as

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

On 2018-06-15 10:23:36 -0500 (-0500), Matthew Thode wrote: [...] > Not sure it'd help but one option we do is to create aliases based > on the title. Though since the PTLs don't have addresses on the > openstack domain an alias may not make as much sense, it'd have to > be a full account forward.

Re: [openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

On 18-06-15 15:00:50, Jeremy Stanley wrote: > Governance tooling change https://review.openstack.org/575554 is > currently up for review to start displaying current PTL E-mail > addresses on the team specific pages linked from the projects index >

[openstack-dev] [nova] [placement] placement update 18-24

HTML: https://anticdent.org/placement-update-18-24.html This is placement update 18-24, a weekly update of ongoing development related to the [OpenStack](https://www.openstack.org/) [placement service](https://developer.openstack.org/api-ref/placement/). It's been quite a while since the last

[openstack-dev] [tc] [ptl] PTL E-mail addresses on rendered team pages

Governance tooling change https://review.openstack.org/575554 is currently up for review to start displaying current PTL E-mail addresses on the team specific pages linked from the projects index https://governance.openstack.org/tc/reference/projects/ page. Since

Re: [openstack-dev] [barbican] NEW weekly meeting time

+1 This is a great time. On 6/14/18, 4:30 PM, "Ade Lee" wrote: >The new time slot has been pretty difficult for folks to attend. >I'd like to propose a new time slot, which will hopefully be more >amenable to everyone. > >Tuesday 12:00 UTC >

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

Hi Thomas, Yes. If you have more than 1 volume node, or 1 volume node with multiple backends definitions. Each volume node should have at least one [backend] that will point to your storage configuration. You can add that config for each of them. Erlon Em sex, 15 de jun de 2018 às 09:52, Thomas

Re: [openstack-dev] [cinder] [placement] cinder + placement forum session etherpad

On Fri, 15 Jun 2018, Eric Fried wrote: We just merged an initial pass at direct access to the placement service [1]. See the test_direct suite for simple usage examples. Note that this was written primarily to satisfy the FFU use case in blueprint reshape-provider-tree [2] and therefore

[openstack-dev] [tricircle] Zuul v3 integration status

Is there anyone who can speak to the status of tricircle's adoption of Zuul v3? As per [1] it doesn't seem like the project is setup properly for Zuul v3. Thus, it's difficult/impossible to land patches like [2] that require neutron/master + a depends on patch. Assuming tricircle is still being

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Fri, Jun 15, 2018 at 3:12 AM, Michele Baldessari wrote: > On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: >> During the Storyboard session today: >> https://etherpad.openstack.org/p/continuing-the-migration-lp-sb >> >> We mentioned that TripleO would continue to migrate during

Re: [openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Excerpts from Ghanshyam's message of 2018-06-15 09:04:35 +0900: > > > > On Fri, 15 Jun 2018 06:17:34 +0900 Doug Hellmann > wrote > > Excerpts from Doug Hellmann's message of 2018-06-14 13:02:31 -0400: > > > Excerpts from Ghanshyam's message of 2018-06-14 16:54:33 +0900: > > >

Re: [openstack-dev] [cinder] [placement] cinder + placement forum session etherpad

We just merged an initial pass at direct access to the placement service [1]. See the test_direct suite for simple usage examples. Note that this was written primarily to satisfy the FFU use case in blueprint reshape-provider-tree [2] and therefore likely won't have everything cinder needs. So

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Mon, Jun 11, 2018 at 10:14:33AM -0500, Eric Fried wrote: > I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. Yeah, I agree with that, if we can't arrive at a sensible limit for Nova, after testing with all drivers that

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

Excerpts from Balázs Gibizer's message of 2018-06-15 13:34:09 +0200: > > On Fri, Jun 15, 2018 at 11:36 AM, Chen CH Ji > wrote: > > on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to > > fail on requirements-check with following error in [2] > > > > Validating lower

Re: [openstack-dev] [cinder] backups need reserved space for LVM snapshots: do we have it implemented already?

On 06/14/2018 01:10 PM, Erlon Cruz wrote: > Hi Thomas, > > The reserved_percentage *is* taken in account for non thin provisoning > backends. So you can use it to spare the space you need for backups. It > is a per backend configuration. Oh. Reading the doc, I thought it was only for thin

Re: [openstack-dev] [nova] review runways check-in and feedback

On Wed, Jun 13, 2018 at 10:33 PM, melanie witt wrote: Howdy everyone, We've been experimenting with a new process this cycle, Review Runways [1] and we're about at the middle of the cycle now as we had the r-2 milestone last week June 7. I wanted to start a thread and gather thoughts

Re: [openstack-dev] [tc] [summary] Organizational diversity tag

I think PTLs would naturally like to have those updated, and for me a TC +w would make sense. But we need to have guidelines, so that's it's more tangible, and the subtlety stays impartial. __ OpenStack Development Mailing

Re: [openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

On Fri, Jun 15, 2018 at 11:36 AM, Chen CH Ji wrote: on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to fail on requirements-check with following error in [2] Validating lower constraints of test-requirements.txt *** Incompatible requirement found! *** See

Re: [openstack-dev] [neutron] Question on the OVS configuration

Apologize for having sent this question to a dev mailing list first! But I humbly request to continue the discussion here. My VM is connect to a private network under demo project, here is the info of the network: $ openstack network show 64f4f4dc-a851-486a-8789-43b816d9bf3d

Re: [openstack-dev] [neutron] Question on the OVS configuration

Please send info about network to which You vm is connected and config of all bridges from ovs also. > Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 11:18: > > Thanks Slawomir for your reply, so what's the right configuration if I want > my VM could be able to access

[openstack-dev] [requirements][nova] weird error on 'Validating lower constraints of test-requirements.txt'

on patch [1] , PS 50 and PS51 just a minor rebase but PS51 start to fail on requirements-check with following error in [2] Validating lower constraints of test-requirements.txt *** Incompatible requirement found! *** See http://docs.openstack.org/developer/requirements but it doesn't provide

Re: [openstack-dev] [neutron] Question on the OVS configuration

Sure, I will. I just think neutron guys should know this better. Best Regards, Dave Chen -Original Message- From: Slawomir Kaplonski [mailto:skapl...@redhat.com] Sent: Friday, June 15, 2018 5:16 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re:

Re: [openstack-dev] [neutron] Question on the OVS configuration

Thanks Slawomir for your reply, so what's the right configuration if I want my VM could be able to access external with physical NIC "eno2"? Do I still need add that NIC into "br-ex"? Best Regards, Dave Chen -Original Message- From: Slawomir Kaplonski [mailto:skapl...@redhat.com]

Re: [openstack-dev] [neutron] Question on the OVS configuration

Also, I think that You should sent such emails to openst...@lists.openstack.org or openstack-operat...@lists.openstack.org in the future :) > Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17: > > Dear folks, > > I have setup a pretty simple OpenStack cluster in

Re: [openstack-dev] [tripleo] Migration to Storyboard

On Mon, May 21, 2018 at 01:58:26PM -0700, Emilien Macchi wrote: > During the Storyboard session today: > https://etherpad.openstack.org/p/continuing-the-migration-lp-sb > > We mentioned that TripleO would continue to migrate during Rocky cycle. > Like Alex mentioned in this thread, we need to

Re: [openstack-dev] [neutron] Question on the OVS configuration

Hi, If You have vxlan network than traffic from it is going via vxlan tunnel which is in br-tun bridge instead of br-ex. > Wiadomość napisana przez dave.c...@dell.com w dniu 15.06.2018, o godz. 10:17: > > Dear folks, > > I have setup a pretty simple OpenStack cluster in our lab based on

[openstack-dev] [neutron] Question on the OVS configuration

Dear folks, I have setup a pretty simple OpenStack cluster in our lab based on devstack, couples of guest VM are running on one controller node (this doesn't looks like a right behavior anyway), the Neutron network is configured as OVS + vxlan, the bridge "br-ex" configured as below:

Re: [openstack-dev] Reminder to add "nova-status upgrade check" to deployment tooling

On 13-06-18 10:14:32, Matt Riedemann wrote: > I was going through some recently reported nova bugs and came across [1] > which I opened at the Summit during one of the FFU sessions where I realized > the nova upgrade docs don't mention the nova-status upgrade check CLI [2] > (added in Ocata). > >

Re: [openstack-dev] [tripleo] Proposing Alan Bishop tripleo core on storage bits

+1 On Wed, Jun 13, 2018 at 08:50:23AM -0700, Emilien Macchi wrote: > Alan Bishop has been highly involved in the Storage backends integration in > TripleO and Puppet modules, always here to update with new features, fix > (nasty and untestable third-party backends) bugs and manage all the >