Re: [openstack-dev] [Zun] Proposal a change of Zun core team

+1 for me. Thanks, Pradeep Singh On Sat, Apr 29, 2017 at 9:35 AM, Hongbin Lu wrote: > Hi all, > > > > I proposes a change of Zun’s core team memberships as below: > > > > + Feng Shengqin (feng-shengqin) > > - Wang Feilong (flwang) > > > > Feng Shengqin has contributed a

[openstack-dev] [Zun] Proposal a change of Zun core team

Hi all, I proposes a change of Zun's core team memberships as below: + Feng Shengqin (feng-shengqin) - Wang Feilong (flwang) Feng Shengqin has contributed a lot to the Zun projects. Her contribution includes BPs, bug fixes, and reviews. In particular, she completed an essential BP and had a

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

This looks like a simple and elegant way to solve the issue. 100% supported by me (and hopefully others). Thanks for addressing it. Renat On 29 Apr 2017, 06:19 +0700, Monty Taylor , wrote: > On 04/28/2017 06:07 PM, Adrian Turjak wrote: > > > > This sounds like a

Re: [openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

Monty, I guess the obligatory joke “It is going to be a Rocky release ahead!” must be made. \o/ Regards -steve -Original Message- From: Monty Taylor Reply-To: "OpenStack Development Mailing List (not for usage questions)"

Re: [openstack-dev] [User-committee] [Forum] Moderators needed!

Shamail, I can moderate either Achieving Resiliency at Scales of 1000+ or High Availability in

Re: [openstack-dev] [Openstack] All Hail our Newest Release Name - OpenStack Rocky

Hi, It would also be nice to actually get an email to vote. I haven't seen one. :) Not that I'm not ok with the name, just saying that it may be worth exploring what happened. Ihar On Fri, Apr 28, 2017 at 3:34 PM Morgan Fainberg wrote: > It would be nice if there

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

On 04/28/2017 06:07 PM, Adrian Turjak wrote: This sounds like a fantastic​ path forward as the version in the service ​ type is a source​ of frustration in some ways. I personally love the version​less discoverability of Keystone as an API model. ++ ... I'll follow up on Monday with an email

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

I love this. Will it be done by July 20th [1] so I can use it in Pike for [2]? [1] https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule [2] https://review.openstack.org/#/c/458257/4/nova/utils.py@1508 On 04/28/2017 05:26 PM, Monty Taylor wrote: > Hey everybody! > > Yay! (I'm sure you're

Re: [openstack-dev] [Openstack] All Hail our Newest Release Name - OpenStack Rocky

It would be nice if there was a bit more transparency on the "legal risk" (conflicts with another project, etc), but thanks for passing on the information none-the-less. I, for one, welcome our new "Rocky" overlord project name :) Cheers, --Morgan On Fri, Apr 28, 2017 at 2:54 PM, Monty Taylor

[openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

Hey everybody! Yay! (I'm sure you're all saying this, given the topic. I'll let you collect yourself from your exuberant celebration) == Background == As I'm sure you all know, we've been trying to make some hearway for a while on getting service-types that are registered in the keystone

Re: [openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

On 04/28/2017 05:54 PM, Monty Taylor wrote: > Hey everybody! > > There isn't a ton more to say past the subject. The "R" release of > OpenStack shall henceforth be known as "Rocky". > > I believe it's the first time we've managed to name a release after a > community member - so please

[openstack-dev] All Hail our Newest Release Name - OpenStack Rocky

Hey everybody! There isn't a ton more to say past the subject. The "R" release of OpenStack shall henceforth be known as "Rocky". I believe it's the first time we've managed to name a release after a community member - so please everyone buy RockyG a drink if you see her in Boston. For

Re: [openstack-dev] [User-committee] [Forum] Moderators needed!

Hi Shamail. Alan Meadows will still be doing the Cloud-Native Design/Refactoring across OpenStack session. He just forgot to confirm that. Please accept my message here as his confirmation. -Andy From: Shamail Tahir [mailto:itzsham...@gmail.com] Sent: Friday, April 28, 2017 7:23 AM To:

Re: [openstack-dev] [qa][gate] tempest slow - where do we execute them in gate?

On 4/17/2017 1:55 PM, Ihar Hrachyshka wrote: But since it's not executed anywhere in tempest gate, even as non-voting (?), it's effectively dead code that may be long broken without anyone knowing. Of course there are consumers of the tests downstream, but for those consumers it's a tough call

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

See - this is what happens when I write an entirely too long email while on coffee number one. :) Yes - you are, obviously, entirely right. I had clearly blocked memory of those pieces out of my memory. I still blame the coffee. It's down to the round-robin impl. Thanks for keeping me

Re: [openstack-dev] [neutron] stepping down from neutron core team

Thanks for all of your work. Come back soon. ;) On Apr 28, 2017 05:02, "Miguel Angel Ajo Pelayo" wrote: > > Hi everybody, > > Some of you already know, but I wanted to make it official. > > Recently I moved to work on the networking-ovn component, > and OVS/OVN

[openstack-dev] [ironic] summary of the virtual meetup

Hi all! We had a virtual meetup on Tuesday, he's a short summary. Detailed notes are here: https://etherpad.openstack.org/p/ironic-virtual-meetup We went over the priorities list to figure out what changes have to be made to accommodate the recent team changes. Four priorities found new

Re: [openstack-dev] [neutron] stepping down from neutron core team

Hello, Thank you for all Your help. Good luck in Your new projects :) — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Miguel Angel Ajo Pelayo w dniu > 28.04.2017, o godz. 11:02: > > > Hi everybody, > > Some of you already know,

[openstack-dev] [docs] OpenStack documentation: Forum session

Hi All, I’m reaching out to you to draw your attention to a Forum topic we proposed with Alex (OpenStack Manuals PTL): https://www.openstack.org/summit/boston-2017/summit-schedule/events/18939/openstack-documentation-the-future-depends-on-all-of-us

Re: [openstack-dev] [ironic] Goodbye ironic o/

Thanks Mario, it was a pleasure to work with you! You did help us a lot during this (unfortunately short) time as an Ironic core. As it usually is, you're welcome to be fast-forwarded back in the team, if the stars align for you to get back to ironic. Good luck with your new assignments! On

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

If it's *just* glance we're making an exception for, I prefer #1 (don't deprecate/remove [glance]api_servers). It's way less code & infrastructure, and it discourages others from jumping on the multiple-endpoints bandwagon. If we provide endpoint_override_list (handwave), people will think it's

[openstack-dev] [ironic] Goodbye ironic o/

Hi ironic team, You may have noticed a decline in my upstream contributions the past few weeks. Unfortunately, I'm no longer being paid to work on ironic. It's unlikely that I'll be contributing enough to keep up with the project in my new job, too, so please do feel free to remove my core

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 10:50 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> if the sack is unlocked, then it means a processing worker isn't looking >> at the sack, and when it does lock the sack, it first has to check sack >> for existing measures to process and then check

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 10:50 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> if the sack is unlocked, then it means a processing worker isn't looking >> at the sack, and when it does lock the sack, it first has to check sack >> for existing measures to process and then check

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Well, endpoint_overrride itself is already a concept with keystoneauth and all of the various client libraries (and more generally is already a concept in consuming the API services) It's a singleton - so we'd need to add a concept of an endpoint_override_list (*handwave on name*) Oh - oops -

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Maybe we are talking about two different things here? I’m a bit confused. Our Glance config in nova.conf on HV’s looks like this: [glance] api_servers=http://glance1:9292,http://glance2:9292,http://glance3:9292,http://glance4:9292 glance_api_insecure=True glance_num_retries=4

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 10:11 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> refresh i believe is always disabled by default regardless of what >> interface you're using. > > You gotta to show me where it is 'cause I can't see that and I don't > recall any option for that. :/

Re: [openstack-dev] [Openstack][Neutron]Why we use secuirity group which only support dispatching whiltelist rules?

2017-04-28 7:03 GMT+09:00 Monty Taylor : > On 04/25/2017 10:32 AM, Gary Kotton wrote: >> >> Hi, >> I would like us to think of considering enabling an API that would allow >> ‘deny’, for example an admin could overwrite a tenant’s security groups. For >> example, and admin

Re: [openstack-dev] [Openstack] [openstack] API to get tunnel port connect to other host

Hi Vikash, The VXLAN tunnel endpoint address is listed in the output of a neutron agent-show : $ neutron agent-show cb45e3f8-4a28-475a-994d-83bc27806c38 +-++ | Field | Value |

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

On Mon, Apr 24, 2017 at 10:43 PM, Emilien Macchi wrote: > On Mon, Apr 17, 2017 at 1:03 PM, Emilien Macchi wrote: >> On Wed, Apr 12, 2017 at 2:47 AM, Tony Breeds wrote: >>> Hi all, >>> I'm late in sending this announement, but

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On Fri, Apr 28 2017, gordon chung wrote: > if the sack is unlocked, then it means a processing worker isn't looking > at the sack, and when it does lock the sack, it first has to check sack > for existing measures to process and then check indexer to validate that > they are still active.

Re: [openstack-dev] [Openstack-operators] [Forum] Moderators needed!

I can moderate HA session if you want (although there is one listed in schedule?). Feel free to sign me up On 28 April 2017 at 06:07, Jay Pipes wrote: > On 04/28/2017 08:22 AM, Shamail Tahir wrote: >> >> Hi everyone, >> >> Most of the proposed/accepted Forum sessions

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Ok. That would solve some of the problem for us, but we’d still be losing the redundancy. We could do some HAProxy tricks to route around downed services, but it wouldn’t handle the case when that one physical box is down. Is there some downside to allowing endpoint_override to remain a list?

Re: [openstack-dev] [kolla] Which distros are used as base ones?

We tried to use mariadb package few months ago, but it turns out it was ancient version that broke horribly on multinode.. On 28 April 2017 at 02:41, Christian Berendt wrote: > >> On 27. Apr 2017, at 11:46, Marcin Juszkiewicz >>

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Thank you both for your feedback - that's really helpful. Let me say a few more words about what we're trying to accomplish here overall so that maybe we can figure out what the right way forward is. (it may be keeping the glance api servers setting, but let me at least make the case real

Re: [openstack-dev] [neutron] stepping down from neutron core team

Tocayo, Good luck! On Fri, Apr 28, 2017 at 4:02 AM, Miguel Angel Ajo Pelayo < majop...@redhat.com> wrote: > > Hi everybody, > > Some of you already know, but I wanted to make it official. > > Recently I moved to work on the networking-ovn component, > and OVS/OVN itself, and while

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On Fri, Apr 28 2017, gordon chung wrote: > refresh i believe is always disabled by default regardless of what > interface you're using. You gotta to show me where it is 'cause I can't see that and I don't recall any option for that. :/ > in the case of cross-metric aggregations, this is a

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

Blair, Mike- There will be an endpoint_override that will bypass the service catalog. It still only takes one URL, though. Thanks, Eric (efried) On 04/27/2017 11:50 PM, Blair Bethwaite wrote: > We at Nectar are in the same boat as Mike.

[openstack-dev] [tripleo] CI Squad Meeting Summary (week 17)

If the topics below interest you and you want to contribute to the discussion, feel free to join the next meeting: Time: Thursdays, 14:30-15:30 UTC Place: https://bluejeans.com/4113567798/ Full minutes: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting Our meeting was an hour later as

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 09:23 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> what if we just don't lock ever on delete, but if we still check lock to >> see if it's processed. at that point, the janitor knows that metric(s) >> is deleted, and since no one else is working on sack,

Re: [openstack-dev] [tooz] etcd3 driver

On 04/28/2017 09:25 AM, Julien Danjou wrote: On Sun, Mar 19 2017, Jay Pipes wrote: Jay, are you working or planning to work on the group interface soon? I'm planning to take a look at it ASAP now but I'd hate to duplicate any work. :) Go for it, JD! :) I had not had that on my plate, no, so

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 09:19 AM, Julien Danjou wrote: > That's not what I meant. You can have the same mechanism as currently, > but then you compute the sacks of all metrics and you > itertools.groupby() per sack on them before locking the sack and > expunging them. yeah, we should do that. i'll add that

[openstack-dev] [tooz] etcd3 driver (was: [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM)

On Sun, Mar 19 2017, Jay Pipes wrote: Jay, are you working or planning to work on the group interface soon? I'm planning to take a look at it ASAP now but I'd hate to duplicate any work. :) > Also, I gave a stab at an etcd3 tooz coordination driver: > > https://review.openstack.org/#/c/447223/ >

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On Fri, Apr 28 2017, gordon chung wrote: > what if we just don't lock ever on delete, but if we still check lock to > see if it's processed. at that point, the janitor knows that metric(s) > is deleted, and since no one else is working on sack, any metricd that > follows will also know that

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On Fri, Apr 28 2017, gordon chung wrote: > so the tradeoff here is that now we're doing a lot more calls to > indexer. additionally, we're pulling a lot more unused results from db. > a single janitor currently just grabs all deleted metrics and starts > attempting to clean them up one at a

Re: [openstack-dev] [gnocchi] Moving python-gnocchiclient to GitHub

On Fri, Apr 28 2017, Javier Pena wrote: > I see none of the tags or branches have been moved over, could they be copied? > It would of great help to packagers. Oh for sure, that's my mistake, I pushed all branches and old tags! Thanks for noting! -- Julien Danjou -- Free Software hacker --

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 03:48 AM, Julien Danjou wrote: > Yes, I wrote that in a review somewhere. We need to rework 1. so > deletion happens at the same time we lock the sack to process metrics > basically. We might want to merge the janitor into the worker I imagine. > Currently a janitor can grab metrics

Re: [openstack-dev] [Openstack-operators] [Forum] Moderators needed!

On 04/28/2017 08:22 AM, Shamail Tahir wrote: Hi everyone, Most of the proposed/accepted Forum sessions currently have moderators but there are six sessions that do not have a confirmed moderator yet. Please look at the list below and let us know if you would be willing to help moderate any of

Re: [openstack-dev] [nova] Compute Node restart

On 27 April 2017 at 06:45, Ajay Kalambur (akalambu) wrote: > I am just issuing a reboot command on the compute node > > Not a reboot –f > > From: Mark Mielke > Date: Wednesday, April 26, 2017 at 8:42 PM > To: "OpenStack Development Mailing List (not for

[openstack-dev] [nova] placement/resource providers update 21

Placement and resource providers update 21. Please let me know if anything is incorrect or missing. If you're going to be in Boston there are some placement related sessions that may be worth your while: * Scheduler Wars: A New Hope

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On 28/04/17 03:48 AM, Julien Danjou wrote: > > Yes, I wrote that in a review somewhere. We need to rework 1. so > deletion happens at the same time we lock the sack to process metrics > basically. We might want to merge the janitor into the worker I imagine. > Currently a janitor can grab

Re: [openstack-dev] [gnocchi] Moving python-gnocchiclient to GitHub

- Original Message - > On Tue, Apr 25 2017, Julien Danjou wrote: > > > We're in the process of moving python-gnocchiclient to GitHub. The > > patches are up for review: > > > > https://review.openstack.org/#/c/459748/ > > > > and its dependencies need to be merged before this happen.

[openstack-dev] [Forum] Moderators needed!

Hi everyone, Most of the proposed/accepted Forum sessions currently have moderators but there are six sessions that do not have a confirmed moderator yet. Please look at the list below and let us know if you would be willing to help moderate any of these sessions. The topics look really

[openstack-dev] [openstack] API to get tunnel port connect to other host

Is there any neutron API, which returns the tunnel port details connected to other host ? For eg. I have Host-A and Host-B. Is there a way to know what is the tunnel-port on Host-A which connects Host-B ? Can't use OVS commands directly. -- Regards, Vikash

Re: [openstack-dev] [neutron] stepping down from neutron core team

Thanks a lot for all that you've done! Wish you all the best! On Fri, Apr 28, 2017 at 1:04 PM Miguel Angel Ajo Pelayo wrote: > > Hi everybody, > > Some of you already know, but I wanted to make it official. > > Recently I moved to work on the networking-ovn

Re: [openstack-dev] [gnocchi] Moving python-gnocchiclient to GitHub

On Tue, Apr 25 2017, Julien Danjou wrote: > We're in the process of moving python-gnocchiclient to GitHub. The > patches are up for review: > > https://review.openstack.org/#/c/459748/ > > and its dependencies need to be merged before this happen. As soon as > this patch is merged, the

Re: [openstack-dev] [Blazar] Meeting time slots in Boston

Le 21/04/2017 06:41, Masahito MUROI a écrit : > Hi all, > > Thanks for choosing time slots! Based on the table of Doodle, I'd like > to pick following two slots for Blazar team meeting. > > 1. 1pm-4pm on Monday for Blazar's internal features > 2. 9am-10am or 11am on Thursday for discussions

Re: [openstack-dev] [kolla] Which distros are used as base ones?

> On 27. Apr 2017, at 11:46, Marcin Juszkiewicz > wrote: > > Does someone care about Ubuntu? Yes, we do. We are using the Ubuntu source images with the Newton and Ocata branches from kolla/kolla-ansible. Christian. -- Christian Berendt Chief Executive

Re: [openstack-dev] [keystone]oslo.config 4.0 will break projects' unit test

Most projects landed fixes for oslo.config 4.0. Keystone needs more effort to make the unit test pass. In addition to https://review.openstack.org/#/c/455391/ which fixes most of failures. There are other failures [1] , I created a bug [2] for Keytone. These chagnes are related with Keystone

[openstack-dev] [neutron] stepping down from neutron core team

Hi everybody, Some of you already know, but I wanted to make it official. Recently I moved to work on the networking-ovn component, and OVS/OVN itself, and while I'll stick around and I will be available on IRC for any questions I'm already not doing a good work with neutron reviews,

[openstack-dev] [nova] allow vfs to be trusted

Hello Matt, There is a serie of patches pushed upstream [0] to configure virtual functions of a SRIOV device to be "trusted". That is to fix an issue when bonding two SRIOV nics in failover mode, basically without that capabability set to the VFs assigned, the guest would not have the privilege

Re: [openstack-dev] [qa][heat][murano][daisycloud] Removing Heat support from Tempest

On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra wrote: > On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli < > andrea.fritt...@gmail.com> wrote: > >> Dear stackers, >> >> starting in the Liberty cycle Tempest has defined a set of projects which >> are in scope for direct >>

Re: [openstack-dev] [nova] Discussions for DPDK support in OpenStack

On Fri, 2017-04-28 at 13:23 +0900, TETSURO NAKAMURA wrote: > Hi Nova team, > > I'm writing this e-mail because I'd like to have a discussion about > DPDK support at OpenStack Summit in Boston. > > We have developed a dpdk-based patch panel named SPP[1], and we'd > like to start working on

Re: [openstack-dev] [qa][heat][murano][daisycloud] Removing Heat support from Tempest

On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli wrote: > Dear stackers, > > starting in the Liberty cycle Tempest has defined a set of projects which > are in scope for direct > testing in Tempest [0]. The current list includes keystone, nova, glance, > swift, cinder

Re: [openstack-dev] [gnocchi] per-sack vs per-metric locking tradeoffs

On Thu, Apr 27 2017, gordon chung wrote: > so as we transition to the bucket/shard/sack framework for incoming > writes, we've set up locks on the sacks so we only have one process > handling any given sack. this allows us to remove the per-metric locking > we had previously. yay! > the

Re: [openstack-dev] [kolla] Which distros are used as base ones?

W dniu 27.04.2017 o 17:16, Michał Jastrzębski pisze: > On 27 April 2017 at 02:46, Marcin Juszkiewicz > wrote: >> Hi >> >> When I joined Kolla project I got info that Debian is going away. So I >> took care of it and now it is updated to current 'testing' and has

Re: [openstack-dev] [nova] Discussions for DPDK support in OpenStack

Get information that DPDK removed ivshmem from http://dpdk.org/ml/archives/dev/2016-July/044552.html -Original Message- From: TETSURO NAKAMURA [mailto:nakamura.tets...@lab.ntt.co.jp] Sent: Friday, April 28, 2017 12:23 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev]