[openstack-dev] [os-upstream-institute] Meeting reminder

Hi Training Team, Friendly reminder that we have our next meeting in less than an hour (2000 UTC) on #openstack-meeting-3. You can find the agenda here: https://etherpad.openstack.org/p/openstack-upstream-institute-meetings See you soon! :) Thanks, Ildikó (IRC: ildikov)

[openstack-dev] [FEMDC] Wed. 6 Dec - IRC Meeting 15:00 UTC

Dear all, A gentle reminder for our Wednesday meeting at 15:00 UTC A draft agenda is available at line 1547, you are very welcome to add any item. https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017

Re: [openstack-dev] [python-openstacksdk][shade] New cores proposed for shade/sdk

On 11/30/2017 10:00 AM, Dean Troyer wrote: On Thu, Nov 30, 2017 at 8:00 AM, Monty Taylor wrote: So let's add them to the core team, yeah? +1 dt Hearing no dissent I've added both. Welcome aboard!

Re: [openstack-dev] [rally]404 on docker rallyforge/rally

Hi, sorry for the inconvenience. docker team removed the rallyforge/rally repo. PTL has contacted them some days ago, but did not get the answer. Let us wait some days, if still not answer, we will create another repo (xrally/rally) for this. Best regards chen

Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

I do believe that was something Tin mentioned after I had talked to him after our IRC chat last week. Seems like the right way to go. Tin? Best, Rohan -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday, December 04, 2017 4:00 PM To: openstack-dev

Re: [openstack-dev] [api] api-sig weekly meeting time change request

). Although I'm not sure how active is the APAC region on either producer or consumer sides. Well there is me at least, +1 for the survey. Thanks, Gilles peace o/ [1]: https://goo.gl/forms/0mVV4TGT7bZGAK323 Cheers, Gilles [1] https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204

Re: [openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

Excerpts from ARORA, ROHAN's message of 2017-12-04 21:47:45 +: > Wanted to start a thread to discuss the potential removal of the Keystoneauth > dependency from Castellan. Whether it is needed or not, approaches we might > want to take, etc. > From my understanding, Tin, Gage, and Ade

[openstack-dev] [octavia] API v2 or v1 or both?

Hi colleagues, when I use in [api_settings] section of octavia.conf api_v1_enabled = False api_v2_enabled = True I'm getting member creation failed: 2017-12-04 22:20:37.326 7199 INFO neutron_lbaas.services.loadbalancer.plugin [req-2c3d3185-9440-4f3d-90de-dff87de783b9

[openstack-dev] Removing Keystoneauth Dependency in Castellan Discussion

Wanted to start a thread to discuss the potential removal of the Keystoneauth dependency from Castellan. Whether it is needed or not, approaches we might want to take, etc. >From my understanding, Tin, Gage, and Ade discussed this at the Sydney summit, >so we were hoping for some

Re: [openstack-dev] [python-openstacksdk][shade] New cores proposed for shade/sdk

Thank You for all Your help and all Your support. I will do my best to help develop shade/sdk projects. — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Monty Taylor w dniu > 04.12.2017, o godz. 22:12: > > On 11/30/2017 10:00 AM, Dean

[openstack-dev] [octavia][tricircle] About enabling automatic installation of octavia with tricircle

Hi, all Tricircle team has already enabled LBaaS with tricircle. Here is the guide https://github.com/openstack/tricircle/blob/master/doc/source/install/installation-lbaas.rst . However, automatic installation and configuration of Octavia in tricircle is not implemented yet, since some

[openstack-dev] [tacker] [hacking] [requirements] pep8 to pycodestyle

We have a change [1] out there which will remove pep8 and use pycodestyle in global requirements. For this change to be merged we need all dependent projects to use the same and check if they have any conflicts. We are waiting for [2] for hacking and [3] for tackerclient to be merged so that we

Re: [openstack-dev] [rally]404 on docker rallyforge/rally

On Tue, Dec 5, 2017 at 5:35 AM, wrote: > Hi, sorry for the inconvenience. > > docker team removed the rallyforge/rally repo. PTL has contacted them some > days ago, but did not get the answer. > > Let us wait some days, if still not answer, we will create another repo >

Re: [openstack-dev] [neutron] [networking-ovn] Non voting jobs for networking-ovn on neutron.

hi, On Mon, Dec 4, 2017 at 10:20 PM, Miguel Angel Ajo Pelayo wrote: > > Hi Folks, > I wanted to rise this topic, I have been wanting to do it from long > ago, > but preferred to wait until the zuulv3 stuff was a little bit more stable, > may > be now it's a good time. >

[openstack-dev] Developer Mailing List Digest November 25 to December 1st

Contribute to the Dev Digest by summarizing OpenStack Dev List thread: * https://etherpad.openstack.org/p/devdigest * http://lists.openstack.org/pipermail/openstack-dev/ * http://lists.openstack.org/pipermail/openstack-sigs HTML version:

[openstack-dev] [ceilometer][cinder]about cinder volume usage

Hello, Right now,we can get volume from central pollester. Then i think may be we can drop cinder volume usage. Cinder volume usage, do not like nova usage which is in nova compute. It is a cmd. And should put it in cron. This will cause more work in devops. If ceilometer pollester can

[openstack-dev] [nova] Notification update week 49

Hi, Here is the status update / focus settings mail for w49 Bugs [Undecided] https://bugs.launchpad.net/nova/+bug/1535254 illustration of 'notify_on_state_change' are different from implementation The fix merged to the master and backports has been proposed to the stable branches

[openstack-dev] [tripleo] Newton promotion job now handled by rdo-phase1

Hello, Just a reminder that tripleo upstream newton promotion job is now handled by rdo-phase1 until the EOL. We are also uploading uploading the overcloud images manually to the upstream mirror server. Kind regards, Arx Cruz

Re: [openstack-dev] [ceilometer] about workload partition

On 2017-12-03 10:30 PM, 李田清 wrote: > > > On 2017-12-01 05:03 AM, 李田清 wrote: > >> Hello, > >>       we test workload partition, and find it's much slower than not > >> using it. > >>       After some review, we find that, after get samples from > >> notifications.sample > >>       

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On Mon, Dec 04 2017, Jaze Lee wrote: > Right now, the dispatch will cost much time in http request. And > keystone auth token cost much time. Although we can configure it to > noauth, then anyone can update gnocchi database which is not we want. > So what about to remove gnocchi http,

[openstack-dev] [rally]404 on docker rallyforge/rally

Hi, Monday morning and it seems that docker images for rally aren't reachable anymore. https://hub.docker.com/r/rallyforge/rally/ Did I miss something ? Is the doc up-to-date[1] ? [1]: http://rally.readthedocs.io/en/0.10.0/install_and_upgrade/install.html#rally-docker Matt

Re: [openstack-dev] [nova] [placement] resource providers update 43

On Sat, Dec 2, 2017 at 3:26 AM, Matt Riedemann wrote: On 12/1/2017 10:42 AM, Chris Dent wrote: > > December? Wherever does the time go? This is resource providers and > placement update 43. The first one of these was more than a year ago > > >

Re: [openstack-dev] [Neutron][ovn] networking-ovn core team update

Congratulations Daniel. Welcome :) Thanks Numan On Fri, Dec 1, 2017 at 10:27 PM, Anil Venkata wrote: > Congrats Daniel > > On 01-Dec-2017 10:22 PM, "Jakub Libosvar" wrote: > >> Congratulations! Very well deserved! :) >> >> On 01/12/2017 17:45,

Re: [openstack-dev] [neutron] Neutron L3 agent/Keepalived

Please, file a bug about that on https://bugs.launchpad.net/neutron/+bugs with tag "l3-ha". On Thu, Nov 30, 2017 at 6:00 AM Ajay Kalambur (akalambu) wrote: > I noticed that this happens when the router HA interface shows status: > Down what can cause the ha interface to do

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

2017-12-04 18:41 GMT+08:00 Julien Danjou : > On Mon, Dec 04 2017, Jaze Lee wrote: > >> Right now, the dispatch will cost much time in http request. And >> keystone auth token cost much time. Although we can configure it to >> noauth, then anyone can update gnocchi database

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On 2017-12-03 10:41 PM, Jaze Lee wrote: > So what about to remove gnocchi http, and add a simple tcp socket, which > will send to gnocchi tcp server(which will also be created.). i'm curious. how does a "simple tcp socket" protect ou against > anyone can update gnocchi database which is not

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

+1 ! Well deserved! On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton wrote: > +1 > > > > Welcome to the team! > > > > *From: *Miguel Lavalle > *Reply-To: *OpenStack List > *Date: *Wednesday, November 29, 2017 at 9:21 PM >

[openstack-dev] [neutron] [networking-ovn] Non voting jobs for networking-ovn on neutron.

Hi Folks, I wanted to rise this topic, I have been wanting to do it from long ago, but preferred to wait until the zuulv3 stuff was a little bit more stable, may be now it's a good time. We were thinking about the option of having a couple of non-voting jobs on the neutron check for

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

Why remove something that works and people are using? If polster can be set up to do the job, then great, but there's no rush to remove the existing infrastructure; this is one case where duplication is very, very cheap. On 4 December 2017 at 10:30, Jaze Lee wrote: > Hello, >

Re: [openstack-dev] [rally]404 on docker rallyforge/rally

On Mon, Dec 4, 2017 at 4:13 PM, Matthieu Simonin wrote: > Hi, > > Monday morning and it seems that docker images for rally aren't reachable > anymore. > > https://hub.docker.com/r/rallyforge/rally/ > > Did I miss something ? Is the doc up-to-date[1] ? > > [1]: >

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On 2017-12-04 05:30 AM, Jaze Lee wrote: > Right now,we can get volume from central pollester. Then i think > may be we can drop cinder volume usage. which metrics are you referring to? just for the record, except for libvirt stats, the polling done by ceilometer is against the API which

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 20:57 GMT+08:00 gordon chung : > > > On 2017-12-04 05:30 AM, Jaze Lee wrote: >> Right now,we can get volume from central pollester. Then i think >> may be we can drop cinder volume usage. > > which metrics are you referring to? just for the record, except for >

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

Thinking about this more ... · Any thoughts on adding a ‘vitrage_alarm_type (enum or short string)’ as a mechanism to identify the general type of problem or alarm being reported in order to address this ? ocould be an optional field obut we’d display in the alarm list oand

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

2017-12-04 20:53 GMT+08:00 gordon chung : > > > On 2017-12-03 10:41 PM, Jaze Lee wrote: >> So what about to remove gnocchi http, and add a simple tcp socket, which >> will send to gnocchi tcp server(which will also be created.). > > i'm curious. how does a "simple tcp socket"

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On Mon, Dec 04 2017, gordon chung wrote: > On 2017-12-04 05:30 AM, Jaze Lee wrote: >> Right now,we can get volume from central pollester. Then i think >> may be we can drop cinder volume usage. > > which metrics are you referring to? just for the record, except for > libvirt stats, the

Re: [openstack-dev] [ironic] this week's priorities and subteam reports

Please ignore this; we didn't have a weekly meeting (because we had our midcycle virtual meet up instead). --ruby From: "Yeleswarapu, Ramamani" Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date:

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

Hi Greg, First, I think that supporting alarm suppression in Vitrage is a very good idea. One question that I have is: I understand that you plan to support it both in the UI and in the CLI. Do you want to the suppression to be per-user? per-tenant? global? Regarding adding

Re: [openstack-dev] [api] api-sig weekly meeting time change request

by 3 hours will negatively impact the EMEA folks. i had sent this survey[1] to the mailing list but didn't get much response. peace o/ [1]: https://goo.gl/forms/0mVV4TGT7bZGAK323 Cheers, Gilles [1] https://www.timeanddate.com/worldclock/meetingtime.html?iso=20171204=195=137=240

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

2017-12-04 19:36 GMT+08:00 Duncan Thomas : > Why remove something that works and people are using? Yes, removing it will make noise. > > If polster can be set up to do the job, then great, but there's no > rush to remove the existing infrastructure; this is one case

[openstack-dev] [neutron] put router in vm rather than namespace

Hello, Can we put router into virtual machine rather than in namespace? Then the HA, and devops will be more elegant. You can live mirage, and use haproxy. The namespace can not be live mirage. It is bind to the host and lose flexible. Or is there some talks or specs about this? -- 谦谦君子

Re: [openstack-dev] [neutron] put router in vm rather than namespace

That adds more latency, I believe some vendor plugins do it like that (service VM). Have you checked out networking-ovn?, it's all done in openflow, and you have Ha (A/P) for free without extra namespaces, just flows and bfd monitoring. On Dec 4, 2017 4:22 PM, "Jaze Lee"

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On Mon, Dec 04 2017, gordon chung wrote: > but at the end of the day, are you building for reality or for some > personal ideal scenario? :p Haha, you know that if I was building for an ideal scenario, most of Ceilometer would probably have never existed in this way. Half of Ceilometer is

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

I am thinking that alarm suppression would be per-tenant. Yeah i am liking the second suggestion, as well, wrt specification of suppressed alarms to be based on { vitrage_type & ‘regexp’ }. Only other reason for introducing vitrage_alarm_type property is perhaps a ‘usability’ type reason i.e.

[openstack-dev] [docs][i18n] Planning for Rocky PTG

Hi all, At the last docs meeting, we agreed to start planning on what docs and i18n topics to focus on during the docs meetup at the upcoming Dublin PTG. Apart from reviewing our progress on action items defined at the previous PTG, we also want to cover other high-priority areas, infrastructure

Re: [openstack-dev] [rally]404 on docker rallyforge/rally

- Mail original - > De: "Swapnil Kulkarni" > À: "OpenStack Development Mailing List (not for usage questions)" > > Envoyé: Lundi 4 Décembre 2017 12:57:36 > Objet: Re: [openstack-dev] [rally]404 on docker rallyforge/rally > > On

Re: [openstack-dev] [ceilometer] remove gnocchi http interface?

On 2017-12-04 09:52 AM, Jaze Lee wrote: > 2017-12-04 20:53 GMT+08:00 gordon chung : >> i'm curious. how does a "simple tcp socket" protect ou against > > I do not quite understand 'protect ou against'. > The tcp socket means it is a client to send samples to gnocchi tcp server. >

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

Either way step one is to propose the code for a better replacement. I doubt you'll get much opposition to that. No need to propose removing the old code immediately, it can live in parallel for as long as needed. On 4 December 2017 at 15:14, Jaze Lee wrote: > 2017-12-04

Re: [openstack-dev] [ceilometer][cinder]about cinder volume usage

On 2017-12-04 08:53 AM, Julien Danjou wrote: > Which is usually a problem because of the APIs, not Ceilometer. They're > sometimes utterly slow for simple things and other times don't offer a > way to retrieve what Ceilometer needs in a batch-y way. > >> in general, there's a preference that

Re: [openstack-dev] [keystone] Queens-2 Retrospective

Just a reminder that this will be happening tomorrow. Since Postfacto is shutting down [0], I've created a new Trello board with a similar feel for tomorrow's retrospective [1]. In order to get the most discussion out of the time we have, the board is open for your input. Please try and take a

Re: [openstack-dev] [vitrage] Feedback on ability to 'suppress' alarms by type and/or resource in Vitrage

Ok, makes sense. Regarding the vitrage_alarm_type: it will be usable only if there are a few alarm types that are used by most datasources. Otherwise it might be just as verbose as the name, IMO. Anyway, you are welcome to propose a blueprint so we can discuss all details there. Best

[openstack-dev] [policy] [rbac] Analyzing other policy systems

Hey all, We had a couple sessions over the last month or two analyzing RBAC in other systems. The notes from the sessions can be found in etherpad [0]. The discussions and outcomes are useful for thinking about how we want things to work in the near future, specifically highlighting the

[openstack-dev] Neutron exception when creating a network using Contrail R4.1 and OpenStack Ocata

Hi all, I am struggling with Contrail R4.1 and OpenStack Ocata on Ubuntu 16.04.2. I managed to install Contrail R4.1 on Ubuntu 16.04 using contrail-installer package and to successfully start all Contrail processes. Then, I installed OpenStack Ocata using devstack. Unfortunately, I am facing