Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

Hi Flint, I wish it was "my" summit ;) In the latter case I'd make the sessions an hour and not 20 or 40 minutes, well at least for the Forum part. And I will also make only one summit a year instead of two (which is also a feed back I got from the Market place). I've passed that during the us

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

On 31/05/18 13:08, Ed Leafe wrote: On May 6, 2018, at 8:01 AM, Gilles Dubreuil wrote: Regarding the choice of Neutron as PoC, I'm sorry for not providing much details when I said "because of its specific data model", effectively the original mention was "its API exposes things at an indivi

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

Hi Gilles, Ed, I’m really glad and thrilled to read such good news! At this point it’s cool to see that many initiatives have the same convergent needs regarding GraphQL as it will give us a good traction from the beginning if our PoC manage to sufficiently convince our peers. Let me know as soo

Re: [openstack-dev] Questions about token scopes

On Thu, May 31, 2018 at 2:09 PM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote: >> >> >> On 05/30/2018 08:47 AM, Matt Riedemann wrote: >>> I know the keystone team has been doing a lot of work on scoped tokens >>> and Lance has been trying to roll that out to othe

Re: [openstack-dev] [tc][forum] TC Retrospective for Queens/Rocky

Doug Hellmann wrote: [...] I'm missing details and/or whole topics. Please review the list and make any updates you think are necessary. One thing that was raised at the Board+TC+UC meeting is the idea of creating a group to help with wording and communication of "help most needed" list items

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

Ade Lee wrote: [...] So it seems that the two blockers above have been resolved. So is it time to ad a castellan compatible secret store to the base services? It's definitely time to start a discussion about it, at least :) Would you be interested in starting a ML thread about it ? If not, th

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

Davanum Srinivas wrote: "master should be always deployable and fully backward compatible and so we cant let anything in anytime that could possibly regress anyone" Should we change that attitude too? Anyone agree? disagree? Thanks, Dims I'll definitely jump at this one. I've always thought

[openstack-dev] Help required to install devstack with GBP

Hi Experts, I have been trying to install devstack with gbp as per the instruction given in the GitHub https://github.com/openstack/group-based-policy This I am running on Ubuntu 16.x as well as 14.x but both the attempts were not successful. It fails stating "neutron is not started" Can you

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Wed, May 30, 2018 at 1:06 PM, Balázs Gibizer wrote: > > > On Tue, May 29, 2018 at 3:12 PM, Sylvain Bauza wrote: > >> >> >> On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer < >> [email protected]> wrote: >> >>> >>> >>> On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza >>> wrote: >>> >>>

Re: [openstack-dev] [oslo] Summit onboarding and project update slides

Thanks Ben 2018-05-31 6:48 GMT+08:00 Ben Nemec : > As promised in the sessions, here are the slides that were presented: > > https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding > > https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update > > The font in the onboarding one got

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza wrote: After considering the whole approach, discussing with a couple of folks over IRC, here is what I feel the best approach for a seamless upgrade : - VGPU inventory will be kept on root RP (for the first type) in Queens so that a comp

[openstack-dev] [sahara] Canceling today's meeting

Hi saharans and interested folks, we won't be having meeting today since at least half of our team is on PTO today. We will be back next Thursday. See you all. -- TELLES NOBREGA SOFTWARE ENGINEER Red Hat Brasil Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

On 2018-05-31 10:33:51 +0200 (+0200), Thierry Carrez wrote: > Ade Lee wrote: > > [...] > > So it seems that the two blockers above have been resolved. So is it > > time to ad a castellan compatible secret store to the base services? > > It's definitely time to start a discussion about it, at least

Re: [openstack-dev] [tc][forum] TC Retrospective for Queens/Rocky

Excerpts from Thierry Carrez's message of 2018-05-31 10:31:12 +0200: > Doug Hellmann wrote: > > [...] > > I'm missing details and/or whole topics. Please review the list and > > make any updates you think are necessary. > > One thing that was raised at the Board+TC+UC meeting is the idea of > cre

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

Yup. I'm sure reviewers will bikeshed the names, but the review is the appropriate place for that to happen. A couple of test changes will also be required. You can have a look at [1] as an example to follow. -efried [1] https://review.openstack.org/#/c/511180/ On 05/31/2018 01:02 AM, Nadathu

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

This seems reasonable, but... On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza wrote: >>> >> >> After considering the whole approach, discussing with a couple of >> folks over IRC, here is what I feel the best approach for a seamless >> upgrade

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

I can do it on xenserver side, although keep old inv in compute node rp looks weird to me(it just work for one case: upgrade)... -Original Message- From: Eric Fried [mailto:[email protected]] Sent: Thursday, May 31, 2018 9:54 PM To: OpenStack Development Mailing List (not for usage ques

Re: [openstack-dev] Questions about token scopes

On 05/30/2018 03:37 PM, Matt Riedemann wrote: > On 5/30/2018 9:53 AM, Lance Bragstad wrote: >> While scope isn't explicitly denoted by an >> attribute, it can be derived from the attributes of the token response. >> > > Yeah, this was confusing to me, which is why I reported it as a bug in > the

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

On Wed, May 30, 2018 at 3:18 PM, Remo Mattei wrote: > Hello all, > I have talked to several people about this and I would love to get this > finalized once and for all. I have checked the OpenStack puppet modules > which are mostly developed by the Red Hat team, as of right now, TripleO is > usin

Re: [openstack-dev] Questions about token scopes

On 05/31/2018 12:09 AM, Ghanshyam Mann wrote: > On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote: >> >> On 05/30/2018 08:47 AM, Matt Riedemann wrote: >>> I know the keystone team has been doing a lot of work on scoped tokens >>> and Lance has been trying to roll that out to other projects

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On 05/29/2018 09:12 AM, Sylvain Bauza wrote: We could keep the old inventory in the root RP for the previous vGPU type already supported in Queens and just add other inventories for other vGPU types now supported. That looks possibly the simpliest option as the virt driver knows that. What do

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On 05/30/2018 07:06 AM, Balázs Gibizer wrote: The nova-manage is another possible way similar to my idea #c) but there I imagined the logic in placement-manage instead of nova-manage. Please note there is no placement-manage CLI tool. Best, -jay ___

[openstack-dev] [release] Release countdown for week R-12, June 4-8

Welcome back to our weekly countdown email. Development Focus - The Rocky-2 milestone deadline is June 7th. Teams should be focused on implementing priority features. General Information --- Membership freeze coincides with milestone 2 [0]. This means projects th

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On 05/31/2018 05:10 AM, Sylvain Bauza wrote: After considering the whole approach, discussing with a couple of folks over IRC, here is what I feel the best approach for a seamless upgrade :  - VGPU inventory will be kept on root RP (for the first type) in Queens so that a compute service upgrad

Re: [openstack-dev] [tripleo][puppet] Hello all, puppet modules

CERN use these puppet modules too and contributes any missing functionality we need upstream. Tim From: Alex Schultz Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Thursday, 31 May 2018 at 16:24 To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] Help required to install devstack with GBP

Hi, Sure we can help you. Could you please take a look at the neutron logs and let me know what exception you are seeing? Also, please let me know which branch you are trying to install. Thanks, ~Sumit. On Thu, May 31, 2018 at 1:52 AM, ., Alex Dominic Savio < [email protected]> wrote:

[openstack-dev] [tc][all] CD tangent - was: A culture change (nitpicking)

On 05/31/2018 03:50 AM, Thierry Carrez wrote: Right... There might be a reasonable middle ground between "every commit on master must be backward-compatible" and "rip out all testing" that allows us to routinely revert broken feature commits (as long as they don't cross a release boundary). T

[openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

Greetings all, I would like to propose the addition of Steve Noyes to the kolla-cli core reviewer team. Consider this nomination as my personal +1. Steve has a long history with the kolla-cli and should be considered its co-creator as probably half or more of the existing code was due to his

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

> My feeling is that we should not attempt to "migrate" any allocations > or inventories between root or child providers within a compute node, > period. While I agree this is the simplest approach, it does put a lot of responsibility on the operators to do work to sidestep this issue, which might

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

+1 On May 31, 2018 at 1:06:43 PM, Borne Mace ([email protected]) wrote: Greetings all, I would like to propose the addition of Steve Noyes to the kolla-cli core reviewer team. Consider this nomination as my personal +1. Steve has a long history with the kolla-cli and should be considered i

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, 31 May 2018, Dan Smith wrote: I kinda think we need to either: 1. Make everything perform the pivot on compute node start (which can be re-used by a CLI tool for the offline case) This sounds effectively like: validate my inventory and allocations at compute node start, correcting t

Re: [openstack-dev] Ceph multiattach support

On 31/05/18 10:00 +0800, fengyd wrote: Hi, I'm using Ceph for cinder backend. Do you have any plan to support multiattach for Ceph backend? Thanks Yafeng Yafeng, Would you describe your use case for cinder multi-attach with ceph backend? I'd like to understand better whether manila (file

[openstack-dev] OpenLab Cross-community Impact

Hi everyone, I know we have sent out quite a bit of information over the past few days with the OpenStack Summit and other updates recently. Additionally there are plenty of meetings we all attend. I just want to take time to point to something very significant in my opinion and again give big tha

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

On Tue, 29 May 2018, Samuel Cassiba wrote: The moniker of 'low-activity' does give the very real, negative perception that things are just barely hanging on. It conveys the subconscious, officiated statement (!!!whether or not this was intended!!!) that nobody in their right mind should consider

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

> 1. Make everything perform the pivot on compute node start (which can be >re-used by a CLI tool for the offline case) > 2. Make everything default to non-nested inventory at first, and provide >a way to migrate a compute node and its instances one at a time (in >place) to roll through

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Rats, typo correction below. On 05/31/2018 01:26 PM, Eric Fried wrote: >> 1. Make everything perform the pivot on compute node start (which can be >>re-used by a CLI tool for the offline case) >> 2. Make everything default to non-nested inventory at first, and provide >>a way to migrate a

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

Back to the topic of nitpicking! I virtually sat down with Doug today and we hammered out the positive aspects that we feel like are the things that we as a community want to see as part of reviews coming out of this effort. The principles change[1] in governance has been updated as a result. I t

[openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

Hello Operators and Devs, This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract common network utilities from nova-network core functionality into separate utility

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, 31 May 2018, Eric Fried wrote: But how would this be accomplished, in light of the current "separation of responsibilities" drawn at the virt driver interface, whereby the virt driver isn't supposed to talk to placement directly, or know anything about allocations? Here's a first pass:

[openstack-dev] [api] notes from api-sig forum meeting on graphql experiment

hi everybody, i have added my notes to the etherpad[1] from summit. briefly, we had a great meeting about creating a graphql experiment in openstack and i tried to capture some of the questions and comments that flew back and forth. there seems to be a good consensus that a proof of concept will

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 3:54 PM, Eric Fried wrote: > This seems reasonable, but... > > On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza > wrote: > >>> > >> > >> After considering the whole approach, discussing with a couple of > >> folks o

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Chris- >> virt driver isn't supposed to talk to placement directly, or know >> anything about allocations? > > For sake of discussion, how much (if any) easier would it be if we > got rid of this restriction? At this point, having implemented the update_[from_]provider_tree flow as we have, it w

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 4:34 PM, Jay Pipes wrote: > On 05/29/2018 09:12 AM, Sylvain Bauza wrote: > >> We could keep the old inventory in the root RP for the previous vGPU type >> already supported in Queens and just add other inventories for other vGPU >> types now supported. That looks possibly

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 5:00 PM, Jay Pipes wrote: > On 05/31/2018 05:10 AM, Sylvain Bauza wrote: > >> After considering the whole approach, discussing with a couple of folks >> over IRC, here is what I feel the best approach for a seamless upgrade : >> - VGPU inventory will be kept on root RP (

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 7:09 PM, Dan Smith wrote: > > My feeling is that we should not attempt to "migrate" any allocations > > or inventories between root or child providers within a compute node, > > period. > > While I agree this is the simplest approach, it does put a lot of > responsibility

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On 05/31/2018 01:09 PM, Dan Smith wrote: My feeling is that we should not attempt to "migrate" any allocations or inventories between root or child providers within a compute node, period. While I agree this is the simplest approach, it does put a lot of responsibility on the operators to do wo

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 7:44 PM, Chris Dent wrote: > On Thu, 31 May 2018, Dan Smith wrote: > > I kinda think we need to either: >> >> 1. Make everything perform the pivot on compute node start (which can be >> re-used by a CLI tool for the offline case) >> > > This sounds effectively like: vali

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 8:26 PM, Eric Fried wrote: > > 1. Make everything perform the pivot on compute node start (which can be > >re-used by a CLI tool for the offline case) > > 2. Make everything default to non-nested inventory at first, and provide > >a way to migrate a compute node an

Re: [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

On 5/31/2018 1:35 PM, melanie witt wrote: This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract common network utilities from nova-network core functionality into

Re: [openstack-dev] [nova] proposal to postpone nova-network core functionality removal to Stein

+openstack-operators On 5/31/2018 3:04 PM, Matt Riedemann wrote: On 5/31/2018 1:35 PM, melanie witt wrote: This cycle at the PTG, we had decided to start making some progress toward removing nova-network [1] (thanks to those who have helped!) and so far, we've landed some patches to extract

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

On 05/30/2018 08:23 PM, Jeremy Stanley wrote: I think this is orthogonal to the thread. The idea is that we should avoid nettling contributors over minor imperfections in their submissions (grammatical, spelling or typographical errors in code comments and documentation, mild inefficiencies in im

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

On 2018-05-31 16:49:13 -0400 (-0400), John Dennis wrote: > On 05/30/2018 08:23 PM, Jeremy Stanley wrote: > > I think this is orthogonal to the thread. The idea is that we should > > avoid nettling contributors over minor imperfections in their > > submissions (grammatical, spelling or typographical

[openstack-dev] Forum Recap - Stein Release Goals

Here's my attempt to recap the goal selection discussion we had last week at the Forum. Feel free to correct any misstatements and continue the discussion. For reference, here's the etherpad from the discussion: https://etherpad.openstack.org/p/YVR-S-release-goals Overall Goal Discussion ===

Re: [openstack-dev] Winterscale: a proposal regarding the project infrastructure

Joshua Hesketh writes: > So the "winterscale infrastructure council"'s purview is quite limited in > scope to just govern the services provided? > > If so, would you foresee a need to maintain some kind of "Infrastructure > council" as it exists at the moment to be the technical design body? For

[openstack-dev] [keystone] failing documentation jobs

Hi all, If you've been trying to write documentation patches, you may have noticed them tripping over unrelated errors when building the docs. We have a bug opened detailing why this happened [0] and a fix working its way through the gate [1]. The docs job should be back up and running soon. [0]

[openstack-dev] [nova][glance] Deprecation of nova.image.download.modules extension point

Hello. We recently upgraded from Liberty to Pike and looking ahead to the code in Queens, noticed the image download deprecation notice with instructions to post here if this interface was in use. As such, I'd like to explain our use case and see if there is a better way of accomplishing our

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

I can help on it. 2018-05-31 21:49 GMT+08:00 Eric Fried : > Yup. I'm sure reviewers will bikeshed the names, but the review is the > appropriate place for that to happen. > > A couple of test changes will also be required. You can have a look at > [1] as an example to follow. > > -efried > > [1

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

+1 On Fri, Jun 1, 2018 at 1:41 AM Mark Giles wrote: > > +1 > > On May 31, 2018 at 1:06:43 PM, Borne Mace ([email protected]) wrote: > > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli > core reviewer team. Consider this nomination as my personal +1. > >

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

+1 Thanks for work, got the good feedback and interest of kolla-cli in *kolla-rocky-ops-and-user-feedback* session in Vancouver. On Thu, May 31, 2018 at 10:32 PM, Borne Mace wrote: > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli core > reviewer team.

[openstack-dev] [tripleo] Containerized Undercloud by default

Hi, During Rocky cycle we would like to switch tripleoclient to deploy containeirzed undercloud by default but before to get there, we want to switch all CI jobs to it, like it was done when enabling config-download by default. Right now we have 3 jobs which test the containerized undercloud: - t

Re: [openstack-dev] [tripleo] Containerized Undercloud by default

I forgot to mention Steve's effort to update the containers when deploying the undercloud, this is a critical piece if we want to continue to test changes in projects like tripleo-common that are embedded in Mistral containers for example. The patch that will enable it is https://review.openstack.o

Re: [openstack-dev] [nova][glance] Deprecation of nova.image.download.modules extension point

On 05/31/2018 04:14 PM, Moore, Curt wrote: The challenge is that transferring the Glance image transfer is _glacially slow_ when using the Glance HTTP API (~30 min for a 50GB Windows image (It’s Windows, it’s huge with all of the necessary tools installed)). If libvirt can instead perform an RB

Re: [openstack-dev] Questions about token scopes

On Thu, May 31, 2018 at 11:24 PM, Lance Bragstad wrote: > > > On 05/31/2018 12:09 AM, Ghanshyam Mann wrote: >> On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad wrote: >>> >>> On 05/30/2018 08:47 AM, Matt Riedemann wrote: I know the keystone team has been doing a lot of work on scoped tokens

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

If Steve wrote half of kolla-cli then it's a no brainer to me. +1! On Thu, May 31, 2018 at 7:02 PM, Borne Mace wrote: > Greetings all, > > I would like to propose the addition of Steve Noyes to the kolla-cli core > reviewer team. Consider this nomination as my personal +1. > > Steve has a long h

[openstack-dev] [Summit][qa] Vancouver Summit 2018 QA Recap

Hi All, We had another good Summit in Vancouver and got good amount of feedback for QA which really important and helpful. I am summarizing the QA discussions during Summit. QA feedback sessions: = Etherpad: https://etherpad.openstack.org/p/YVR18-forum-qa-ops-user-feedback We

Re: [openstack-dev] [kolla][vote] Nominating Steve Noyes for kolla-cli core reviewer

+1 from me:) On Thu, May 31, 2018, 11:40 PM Martin André wrote: > If Steve wrote half of kolla-cli then it's a no brainer to me. +1! > > On Thu, May 31, 2018 at 7:02 PM, Borne Mace wrote: > > Greetings all, > > > > I would like to propose the addition of Steve Noyes to the kolla-cli core > > re