Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

OK, this makes sense. Thanks for clarification! On Wed, Jan 25, 2017 at 10:50 PM Ihar Hrachyshka wrote: > On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday > wrote: > > Thanks for bringing this up! > > > > I was assuming that from Ocata everyone

Re: [openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

I think #3 is the right call for now. The person we had working on privsep has left the company, and I don't have anyone I could get to work on this right now. Oh, and we're out of time. Michael On Thu, Jan 26, 2017 at 3:49 PM, Matt Riedemann wrote: > The patch to add

[openstack-dev] [nova] To rootwrap or piggyback privsep helpers?

The patch to add support for ephemeral storage with the Virtuozzo config is using the privsep helper from os-brick to run a new ploop command as root: https://review.openstack.org/#/c/312488/ I've objected to this because I'm pretty sure this is not how we intended to be using privsep in

[openstack-dev] [nova] Latest and greatest on trying to get n-sch to require placement

This is my public hand off to Sylvain for the work done tonight. Starting with the multinode grenade failure in the nova patch to integrate placement with the filter scheduler: https://review.openstack.org/#/c/417961/ The test_schedule_to_all_nodes tempest test was failing in there because

Re: [openstack-dev] [neutron] API models [was: PTL candidacy]

>This is why it should be easy to do. The easier it is, the more Neutron work you'll have time for, in fact. I agree that writing them should be easy. But I don't want to enable operators to just tweak config files to alter APIs. So +1000 to developer productivity. I just don't want it to

[openstack-dev] [daisycloud-core] Weekly meeting 0800UTC Jan. 27 & Feb. 3 cancelled

Hi Team, Weekly meetings on Jan. 27 & Feb. 3 have been cancelled for Chinese New Year vacation. B. R., Zhijiang__ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [Horizon] [Performance] Gathering quota usage data in Horizon

Hi, guys, Sorry for recalling this thread after 1 year, but we are currently suffering from the poor performance issue for our public cloud. As usage of our customers keeps growing, we are at a stage that should seriously pay more attention to horizon performance problem, so Google took me to

Re: [openstack-dev] [neutron] API models [was: PTL candidacy]

On 25 January 2017 at 18:07, Kevin Benton wrote: > >Setting aside all the above talk about how we might do things for a > moment: to take one specific feature example, it actually took several > /years/ to add VLAN-aware ports to OpenStack. This is an example of a > feature

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

hi, On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann wrote: > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600: >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto : >> > hi, >> > >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.

Re: [openstack-dev] [neutron] PTL candidacy

>There is no such thing as arbitrary API. It is like one person's treasure is other person's trash no body loves to create arbitrary APIs - there are genuine needs. Arbitrary in the sense that new APIs can be developed on-demand to solve one specific use case that leads to fragmentation and

[openstack-dev] [QA] Meeting Thursday Jan 26th at 9:00 UTC

Hello everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, Jan 26th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: *

Re: [openstack-dev] [horizon] FFE Request

I've posted some comments on the API Access patch. The blueprint was saying that 'API Access' would be both at the Project level, but the way panel groups worked meant that setting the 'default' panel group didn't work when that dashboard already had panel groups, since the default panel group

Re: [openstack-dev] [Neutron] PTL Candidacy

I think we may also want to bring this up in a cross-project session at the PTG. We are definitely to blame for some of the instability, but towards the end of this cycle I have noticed lots of issues with HTTPS connection errors, etc that don't seem to be related to Neutron at all. The squad team

Re: [openstack-dev] [neutron] API models [was: PTL candidacy]

>Obviously this is close to my interests, and I see Kevin's raised Gluon as the bogeyman (which it isn't trying to be). No, I was pointing out that it's not what I want Neutron to become. It's entire purpose is to make defining new APIs as simple as writing YAML (i.e. networking APIs as a

Re: [openstack-dev] [kolla][kolla-ansible] How to restart working on a patch started before repo split?

Hi Paul, > To my knowledge it's not possible to change the target repository for an > open patch. What we've done so far is to abandon the in progress one, > cherry-pick to the correct repository and start a new review (adding the > original author as a co-author of course). Thanks for sharing

[openstack-dev] [neutron][networking-vpp]networking-vpp for VPP 17.01 is available

In conjunction with the release of VPP 17.01, I'd like to invite you all to try out networking-vpp for VPP 17.01. VPP is a fast userspace forwarder based on the DPDK toolkit, and uses vector packet processing algorithms to minimise the CPU time spent on each packet and maximise throughput.

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

Thanks rm_work. I also notice something need to be handled properly. For barbican, the delete_cert() only deregisters the cert without actually delete it. That's safe for us to call during delete_listener()/delete_loadbalancer(). But if the user uses other cert_manager by any chance, say the

[openstack-dev] [infra] Pike PTG Etherpad

Just a heads-up I've been meaning to send for a while... as discussed in the last month of Infra meetings we've got a pad here for people to pitch ideas of things they want to collaborate on in the Infra team space at the PTG on Monday and Tuesday:

Re: [openstack-dev] [murano] [ptl] PTL Candidacy for Pike

Felipe, thank you so much for all your efforts so far, I am sure that you will be a great leader for the Murano! On Tue, Jan 24, 2017 at 10:58 AM, MONTEIRO, FELIPE C wrote: > Hi, > > > > My name is Felipe Monteiro. I have decided to run for Murano PTL for the > Pike > > release

Re: [openstack-dev] [horizon] FFE Request

Big Thanks! from me too. The old UI here was very unintuitive, so I had to field a lot of questions related to it. This is great. :) Kevin From: Lingxian Kong [anlin.k...@gmail.com] Sent: Wednesday, January 25, 2017 2:23 PM To: OpenStack Development Mailing List

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

I would like to comment a little bit regarding usage of Glare in Murano and Mirantis OpenStack: > How much have these projects adopted Glare? Glare is preferred backend for storing murano packages, which provides versioning capabilities (they are not available without it) >Is Glare being

Re: [openstack-dev] [neutron] PTL candidacy

On 25 January 2017 at 14:17, Monty Taylor wrote: > > Adding an additional networking project to try to solve this will only > > make things work. We need one API. If it needs to grow features, it > > needs to grow features - but they should be features that all of > >

Re: [openstack-dev] Planning for the Pike PTG

I think the keystone team is in the same spot. We have an etherpad [0] for jotting down ideas, but we haven't parsed it or grouped it in into topics yet. I think we were going to start working on that next week since we're still in the middle of wrapping up the last few bits for ocata-3. I was

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

On 18:16 Jan 24, Mikhail Fedosin wrote: > Hey, Flavio :) Thanks for your questions! > > As you said currently only Nokia's adopting Glare for its own platform, but > if we talk about OpenStack, that I believe Mistral will start to use it > soon. > In my opinion Glare's adoption is low due to the

Re: [openstack-dev] Planning for the Pike PTG

I am preparing for PTG sessions. How much capacity is in each room ? 30 people or more? We might want to have different discussions or coding meetups in parallel in the same room, because each developer concentrates on different working topics (Tempest, Devstack, Grenade, Patrole, etc under QA

Re: [openstack-dev] [horizon] FFE Request

Hi Rob, FFE granted for those two in-flight patches. On 26 January 2017 at 09:23, Lingxian Kong wrote: > Hi, Rob, > > First, thanks for your work! > > What's your plan for the other two tabs (security group, floatingip)? I > could see the split is very helpful no matter

Re: [openstack-dev] [horizon] FFE Request

Hi, Rob, First, thanks for your work! What's your plan for the other two tabs (security group, floatingip)? I could see the split is very helpful no matter from performance perspective and both useful from end user's perspective. BTW, a huge +1 for this FFE! Cheers, Lingxian Kong (Larry)

Re: [openstack-dev] [neutron] PTL candidacy

On 01/25/2017 08:16 AM, Monty Taylor wrote: > On 01/24/2017 06:42 PM, Sukhdev Kapur wrote: >> >> Ihar and Kevin, >> >> As our potential future PTLs, I would like to draw your attention to one >> of the critical issue regarding Neutron as "the" networking service in >> OpenStack. >> >> I keep

Re: [openstack-dev] [TripleO][CI] Running experimental OVB and not OVB jobs separately.

On Wed, Jan 25, 2017 at 3:42 PM, Sagi Shnaidman wrote: > HI, all > > I'd like to propose a bit different approach to run experimental jobs in > TripleO CI. > As you know we have OVB jobs and not-OVB jobs, and different pipelines for > running these two types of them. > > What

[openstack-dev] [TripleO][CI] Running experimental OVB and not OVB jobs separately.

HI, all I'd like to propose a bit different approach to run experimental jobs in TripleO CI. As you know we have OVB jobs and not-OVB jobs, and different pipelines for running these two types of them. What is current flow: if you need to run experimental jobs, you write comment with "check

Re: [openstack-dev] [neutron] API models [was: PTL candidacy]

I would certainly be interested in dicussing this, though I'm not currently signed up for the PTG. Obviously this is close to my interests, and I see Kevin's raised Gluon as the bogeyman (which it isn't trying to be). Setting aside all the above talk about how we might do things for a moment: to

Re: [openstack-dev] Is the gate stuck?

Thanks for the explanation. I agree that it has indeed moved now! On Wed, Jan 25, 2017 at 8:18 PM Jeremy Stanley wrote: > On 2017-01-25 20:05:04 + (+), Neil Jerram wrote: > > I'm not experienced in reading these things, but it seems that nothing is > > currently

Re: [openstack-dev] Is the gate stuck?

On 2017-01-25 20:05:04 + (+), Neil Jerram wrote: > I'm not experienced in reading these things, but it seems that nothing is > currently getting through the integrated gate, and from [1] it appears this > is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has > hung. >

[openstack-dev] Is the gate stuck?

I'm not experienced in reading these things, but it seems that nothing is currently getting through the integrated gate, and from [1] it appears this is because the gate-tempest-dsvm-neutron-full-ubuntu-xenial job of [2] has hung. [1] http://status.openstack.org/zuul/ [2]

Re: [openstack-dev] [horizon] FFE Request

+1We very much need this as the performance of that panel is awful. This solves that problem while being a fairly minor code change which also provides much better UX.On 26/01/2017 8:07 AM, Rob Cresswell wrote: o/  I'd like to request an FFE on 

Re: [openstack-dev] [neutron] [ovo] unhashable type error

Looking at the code, I don't see a clear case to even use set() type there. A list would seem to work just fine. Should we try to convert to using lists there? Nevertheless, we can look into extending the object base class for hashing. I wonder though if it's something to tackle in Neutron scope.

[openstack-dev] [neutron] [ovo] unhashable type error

Hi Ihar, While doing the integration for vlanallocation [1] I found that OVO associated with VlanAllocation throws “unhashable type” error with py35. The associated stack trace is here [2]. To resolve this issue I added an equality and hash method in the vlanallocation OVO [3]. My

Re: [openstack-dev] [tripleo] Update TripleO core members

On 01/23/2017 11:03 AM, Emilien Macchi wrote: > Greeting folks, > > I would like to propose some changes in our core members: > > - Remove Jay Dobies who has not been active in TripleO for a while > (thanks Jay for your hard work!). > - Add Flavio Percoco core on tripleo-common and

Re: [openstack-dev] [requirements][docs] updating the minimum version of sphinx

Excerpts from Andreas Jaeger's message of 2017-01-25 08:40:16 +0100: > On 2017-01-25 08:24, Andreas Jaeger wrote: > > On 2017-01-25 05:03, Matthew Thode wrote: > >> On 01/24/2017 09:57 PM, Matthew Thode wrote: > >>> Basically I'd like to ask the docs people if they are fine with updating > >>>

[openstack-dev] [nova] No cells v2 meeting today 25-Jan

Hi all, Apologies for the late notice, but there won't be a cells meeting this afternoon being that everyone is busy scrambling for the feature freeze deadline this week. Let's catch up after FF. Thanks, -melanie __

[openstack-dev] [horizon] FFE Request

o/ I'd like to request an FFE on https://blueprints.launchpad.net/horizon/+spec/reorganise-access-and-security. This blueprint splits up the access and security tabs into 4 distinct panels. The first two patches are https://review.openstack.org/#/c/408247 and

Re: [openstack-dev] [neutron] PTL candidacy

On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton wrote: > >I would really like us to discuss this issue head-on and see what is > missing in Neutron APIs and what would take to make them extensible so that > vendors do not run around trying to figure out alternative solutions

Re: [openstack-dev] [neutron] change in argument type for allocate_partially_specified_segment

On Tue, Jan 24, 2017 at 10:29 PM, Anna Taraday wrote: > Thanks for bringing this up! > > I was assuming that from Ocata everyone should switch from usage 'old' > TunnelTypeDriver to updated one. I am not sure. We haven't marked the 'old' one with any deprecation

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

I've got this on my list of things to look at -- I don't know if it was you I was talking with on IRC the other day about this issue, but I'm definitely aware of it. As soon as we are past the Ocata feature freeze crunch, I'll take a closer look. My gut says that we should be calling the delete

Re: [openstack-dev] [Neutron] PTL Candidacy

On Tue, Jan 24, 2017 at 12:26 PM, Morales, Victor wrote: > Given the latest issues related with the memory consumption[1] in CI jobs, > I’m just wondering if you have a plan to deal and/or improve it in Neutron. AFAIU the root cause is still not clear, and we don't

Re: [openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

+1 to Dharmendra, great addition. Thank you very much Stephen for your contributions. -Sripriya On 1/24/17, 4:58 PM, "Sridhar Ramaswamy" wrote: Tackers, I'd like to propose following changes to the Tacker core team. Stephen Wong After being

Re: [openstack-dev] [neutron] PTL candidacy

Folks, This thread has gotten too long and hard to follow. It is clear that we should discuss/address this. My suggestion is that we organize a session in Atlanta PTG meeting and discuss this. I am going to add this on the Neutron etherpad - should this be included in any other session as well?

Re: [openstack-dev] [neutron] PTL candidacy

On Wed, Jan 25, 2017 at 7:45 AM, Kevin Benton wrote: > LBaaS is a little special since Octavia will have it's own API endpoint > completely that they will evolve on their own. The other spun-out projects > (e.g. VPNaaS) will have the API defined in neutron-lib[1]. In a way,

Re: [openstack-dev] [neutron] PTL candidacy

Folks, this is a great discussion. I hope this leads us to some good consensus and direction :-) I would suggest that we discuss this in upcoming PTG meeting as well. On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton wrote: > >So I'm not sure that Kevin and Thierry's answers

Re: [openstack-dev] [neutron] PTL candidacy

Catching up on the thread, lots of good thoughts. I don't think there is disagreement here around how Networking API should evolve in terms of vendor extensions. As Kevin suggested, we don't want to advertise API extensibility without Neutron team supervision. One of the reasons behind current

Re: [openstack-dev] [glance] Propose Dharini Chandrasekar for Glance core

My sincere Thanks to every Glance core. You all have inspired me right from day one. I hope to perform my duties as a Glance Core to the best of my abilities and help make Glance great. Thanks, Dharini Chandrasekar. On 1/24/17, 07:36, "Brian Rosmaita" wrote:

Re: [openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

+1 for both. Regards Bharath T Imaginea Technologies Inc. On Wed, Jan 25, 2017 at 8:19 PM, HADDLETON, Robert W (Bob) < bob.haddle...@nokia.com> wrote: > +1 > > Thanks Stephen! And welcome aboard Dharmendra! > > Bob > > > On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote: > >> Tackers, >> >> I'd

Re: [openstack-dev] [tripleo] tripleo-heat-templates, vendor plugins and the new hiera hook

On 01/25/2017 04:32 PM, Steven Hardy wrote: > On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote: >> Hi, as part of the composable upgrades workflow shaping up for Newton to >> Ocata, we need to install the new hiera hook that was first added with >> [1] and disable the old hook and

Re: [openstack-dev] [tripleo][puppet] Preparations for Ocata release in RDO

On Wed, Jan 25, 2017 at 12:13 PM, Javier Pena wrote: >> Hi, >> >> In RDO we are preparing for the incoming Ocata release. This means >> we'll create a new RDO Trunk builder "centos-ocata" in the next few >> days (It will be ready for next week). This builder will get

Re: [openstack-dev] [tripleo] Officially support Python 3.5 in Pike

On Tue, Jan 24, 2017 at 4:39 PM, Emilien Macchi wrote: > OpenStack community decided to officially support Python 3.5 by the > end of Pike cycle: > https://governance.openstack.org/tc/goals/pike/python35.html > > To track this work in TripleO, I created a blueprint: >

Re: [openstack-dev] [tripleo][puppet] Preparations for Ocata release in RDO

> Hi, > > In RDO we are preparing for the incoming Ocata release. This means > we'll create a new RDO Trunk builder "centos-ocata" in the next few > days (It will be ready for next week). This builder will get content > from stable/ocata branches of projects as they become available and >

[openstack-dev] [nova] [placement] placement api request analysis

I've started looking into what kind of request load the placement API can expect when both the scheduler and the resource tracker are talking to it. I think this is important to do now before we have things widely relying on this stuff so we can give some reasonable advice on deployment options

Re: [openstack-dev] [vote][kolla] deprecation for Debian distro support

As discussed in todays team meeting [0]: * the vote is closed * the deprecation is delayed http://eavesdrop.openstack.org/meetings/kolla/2017/kolla.2017-01-25-16.01.log.html Christian. -- Christian Berendt Chief Executive Officer (CEO) Mail: bere...@betacloud-solutions.de Web:

Re: [openstack-dev] Move of openstack-salt project

Filip, Thanks for the announce. Can you please follow the steps below to retire the projects in openstack git repo? http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project Thanks, Dims On Wed, Jan 25, 2017 at 11:39 AM, Filip Pytloun wrote: > Hello, > > I would

[openstack-dev] Move of openstack-salt project

Hello, I would like to announce migration of openstack-salt to join remaining formulas of the ecosystem. Since today, openstack-salt and other formulas are living at github.com/salt-formulas. In the past few years this ecosystem has grown to more than 90 formulas suitable for deployment of

[openstack-dev] [charms] Thursday 2nd February - Bug Day!

Hi Team Just a quick reminder that next Thursday marks our second bug day for the year. Please focus on triage and resolution of bugs across the openstack charms - the new bugs URL is in the topic in #openstack-charms on Freenode IRC. Happy bug hunting! Cheers James

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

> Update on that agreement : I made the necessary modification in the > proposal [1] for not verifying the filters. We now send a request to the > Placement API by introspecting the flavor and we get a list of potential > destinations. Thanks! > When I began doing that modification, I know there

Re: [openstack-dev] [all] [tc] [api] refreshing and revalidating api compatibility guidelines

On 01/25/2017 06:16 AM, Monty Taylor wrote: I have quibble with the current microversions construct. It's mostly semantic in nature, and I _think_ it's not valid/useful - but I'm going to describe it here just so that I've said it and we can all acknowledge it and move on. My concern is with

Re: [openstack-dev] [neutron] PTL candidacy

LBaaS is a little special since Octavia will have it's own API endpoint completely that they will evolve on their own. The other spun-out projects (e.g. VPNaaS) will have the API defined in neutron-lib[1]. The specific DVR issue you are referring to with roaming IPs being the target of floating

[openstack-dev] [watcher] self-nomination as Watcher PTL

I'm happy to announce my candidacy for Watcher PTL for the Pike release cycle. I've been working on OpenStack for 2.5 years as engineer. My contributions have been started in February 2016, they are related to Watcher and Rally projects. I'm very proud of being one of core developers in Watcher

Re: [openstack-dev] [tripleo] tripleo-heat-templates, vendor plugins and the new hiera hook

On Wed, Jan 25, 2017 at 02:59:42PM +0200, Marios Andreou wrote: > Hi, as part of the composable upgrades workflow shaping up for Newton to > Ocata, we need to install the new hiera hook that was first added with > [1] and disable the old hook and data as part of the upgrade > initialization [2].

Re: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui

On Tue, Jan 24, 2017 at 08:52:51AM -0500, Emilien Macchi wrote: > I have been discussed with TripleO UI core reviewers and it's pretty > clear Honza's work has been valuable so we can propose him part of > Tripleo UI core team. > His quality of code and reviews make him a good candidate and it

Re: [openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

On Tue, Jan 24, 2017 at 07:03:56PM +0200, Juan Antonio Osorio wrote: > Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both > on the current CI solution and in getting tripleo-quickstart jobs for > it); So I would like to propose him as part of the TripleO CI core team. > I

Re: [openstack-dev] [tripleo] Update TripleO core members

On Mon, Jan 23, 2017 at 02:03:28PM -0500, Emilien Macchi wrote: > Greeting folks, > > I would like to propose some changes in our core members: > > - Remove Jay Dobies who has not been active in TripleO for a while > (thanks Jay for your hard work!). > - Add Flavio Percoco core on tripleo-common

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Wed, Jan 25 2017, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc. I think "generated" is the wrong word here. Aodh does not generate any alarms: it allows users to create them. And then it evaluates them and

[openstack-dev] [Glance] Ocata-3 Priorities

Hi all, Brian kindly emailed the list last week [1] with our priorities for python-glanceclient and glance. The python-glanceclient priorities have all been effectively reviewed and python-glanceclient has been released. The stable/ocata branch for it now exists as well. If you are reviewing

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 25/01/2017 05:10, Matt Riedemann a écrit : > On 1/24/2017 2:57 PM, Matt Riedemann wrote: >> On 1/24/2017 2:38 PM, Sylvain Bauza wrote: >>> >>> It's litterally 2 days before FeatureFreeze and we ask operators to >>> change their cloud right now ? Looks difficult to me and like I said in >>>

Re: [openstack-dev] [all] [tc] [api] refreshing and revalidating api compatibility guidelines

On 01/25/2017 09:16 AM, Monty Taylor wrote: > On 01/24/2017 12:39 PM, Chris Dent wrote: >> On Mon, 23 Jan 2017, Sean Dague wrote: >> >>> We all inherited a bunch of odd and poorly defined behaviors in the >>> system we're using. They were made because at the time they seemed like >>> reasonable

Re: [openstack-dev] [tacker] Core team changes / proposing Dharmendra Kushwaha

+1 Thanks Stephen! And welcome aboard Dharmendra! Bob On 1/24/2017 6:58 PM, Sridhar Ramaswamy wrote: Tackers, I'd like to propose following changes to the Tacker core team. Stephen Wong After being associated with Tacker project from its genesis, Stephen Wong (irc: s3wong) has decided to

Re: [openstack-dev] [openstack-ansible] Live migration issue

Thanks for reply. But « a priori » log say « this error can be safely ignore ». And therefore, this log comes from the live migration that succeeded (compute 2 to compute 1). The ERROR that questions me is (live migration compute 1 to 2), on compute 1: 2017-01-25 11:03:58.475 113231 ERROR

Re: [openstack-dev] [neutron] PTL candidacy

On 25/01/2017 01:08, Kevin Benton wrote: >>I would really like us to discuss this issue head-on and see what is > missing in Neutron APIs and what would take to make them extensible so > that vendors do not run around trying to figure out alternative > solutions > > The Neutron API is already

[openstack-dev] [I18n] Horizon and Horizon plugins: StringFreeze policies for translation

Hello OpenStack developers! My name is Ian and I am now serving I18n PTL for Ocata cycle. For previous releases, I18n team set higher priorities for translations on Horizon and Horizon plugins during Soft and Hard StringFreezes to include user-faced translated strings as much as possible

Re: [openstack-dev] [tripleo] Update TripleO core members

+1 On 23.1.2017 20:03, Emilien Macchi wrote: Greeting folks, I would like to propose some changes in our core members: - Remove Jay Dobies who has not been active in TripleO for a while (thanks Jay for your hard work!). - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates

Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?

Thanks peeps for responding to Kris. Kris, I had offered a response – do you need further information answered? It looks to me like all the questions have been answered by others in the community. If not, feel free to respond and I’ll answer the remainders. Sean when your around and I am

Re: [openstack-dev] [all] [tc] [api] refreshing and revalidating api compatibility guidelines

On 01/24/2017 12:39 PM, Chris Dent wrote: > On Mon, 23 Jan 2017, Sean Dague wrote: > >> We all inherited a bunch of odd and poorly defined behaviors in the >> system we're using. They were made because at the time they seemed like >> reasonable tradeoffs, and a couple of years later we learned

Re: [openstack-dev] [neutron] PTL candidacy

On 01/24/2017 06:42 PM, Sukhdev Kapur wrote: > > Ihar and Kevin, > > As our potential future PTLs, I would like to draw your attention to one > of the critical issue regarding Neutron as "the" networking service in > OpenStack. > > I keep hearing off and on that Neutron is not flexible to

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On 25/01/17 08:39 AM, Afek, Ifat (Nokia - IL) wrote: > As we see it, alarms can be generated by different sources – Aodh, Vitrage, > Nagios, Zabbix, etc. Each source has its own expertise and internal > implementation. Nagios and Zabbix can raise alarms about the physical layer, > Aodh can

Re: [openstack-dev] [neutron] PTL candidacy

On 01/24/2017 08:04 PM, Kevin Benton wrote: >>I would really like us to discuss this issue head-on and see what is > missing in Neutron APIs and what would take to make them extensible so > that vendors do not run around trying to figure out alternative > solutions > > The Neutron API is

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

Hi, Alarm history and a database are definitely important, but they are not the main issue here. As we see it, alarms can be generated by different sources – Aodh, Vitrage, Nagios, Zabbix, etc. Each source has its own expertise and internal implementation. Nagios and Zabbix can raise alarms

Re: [openstack-dev] [puppet] CI status for Ubuntu

On Tue, Jan 24, 2017 at 6:43 AM, Corey Bryant wrote: > > On Fri, Jan 20, 2017 at 6:34 PM, Alex Schultz wrote: >> >> Just FYI, >> >> We switched the Ubuntu scenario jobs to non-voting this week due to >> the large amount of breakage caused by the

Re: [openstack-dev] [neutron] PTL candidacy

>So I'm not sure that Kevin and Thierry's answers address Sukhdev's point. I stated that I am happy to develop new APIs in Neutron. "So I'm all for developing new APIs *as a community*"... The important distinction I am making is that we can make new APIs (and we do with routed networks as you

Re: [openstack-dev] [tripleo] Update TripleO core members

On 23/01/17 21:03, Emilien Macchi wrote: > Greeting folks, > > I would like to propose some changes in our core members: > > - Remove Jay Dobies who has not been active in TripleO for a while > (thanks Jay for your hard work!). > - Add Flavio Percoco core on tripleo-common and

[openstack-dev] [tripleo] tripleo-heat-templates, vendor plugins and the new hiera hook

Hi, as part of the composable upgrades workflow shaping up for Newton to Ocata, we need to install the new hiera hook that was first added with [1] and disable the old hook and data as part of the upgrade initialization [2]. Most of the existing hieradata was ported to use the new hook in [3]. The

Re: [openstack-dev] [neutron] PTL candidacy

On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez wrote: > Kevin Benton wrote: > > [...] > > The Neutron API is already very extensible and that's problematic. Right > > now a vendor can write an out-of-tree service plugin or driver that adds > > arbitrary fields and

Re: [openstack-dev] [magnum] CoreOS template v2

Hi, I did write a blueprint a while ago but did not start to implement it. https://blueprints.launchpad.net/magnum/+spec/coreos-best-pratice > Le 24 janv. 2017 à 23:16, Spyros Trigazis a écrit : > > Or start writing down (in the BP) what you want to put in the driver. >

Re: [openstack-dev] [Freezer] PTL Candidacy

And you have at least all my support : ) On Wed, Jan 25, 2017 at 12:56 PM, Saad Zaher wrote: > Hello everyone, > > I'm happy to announce my candidacy to be the Freezer PTL for the Pike > release > cycle. > > The Freezer developers did a very good job over the past releases

Re: [openstack-dev] [openstack-ansible] Live migration issue

Hi, What domain name are you using? Check for 'Traceback' and ' ERROR ' in the logs, maybe you will get a hint 2017-01-25 11:00:21.215 28309 INFO nova.compute.manager [req-6f21e4a4-28a8-48e3-bf2f-2e1ad3b52470 0329776bd1634978a7fed35a70c77479 7531f209e3514e3f98eb58aafa480285 - - -] [instance:

[openstack-dev] [Freezer] PTL Candidacy

Hello everyone, I'm happy to announce my candidacy to be the Freezer PTL for the Pike release cycle. The Freezer developers did a very good job over the past releases and I am sure they will continue doing an amazing job over the next release as well. For the Pike release cycle, I think we need

Re: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui

- Original Message - > From: "Emilien Macchi" > To: "OpenStack Development Mailing List" > Sent: Tuesday, January 24, 2017 2:52:51 PM > Subject: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui > > I have been

Re: [openstack-dev] [all] [tc] [api] refreshing and revalidating api compatibility guidelines

On Wed, 25 Jan 2017, Thierry Carrez wrote: We were discussing this in the context of an "assert" tag, not a goal. Yes, but it is often the case that changes are being evaluated as if it was a goal. A couple of glance related changes experienced reactions of "this doesn't meet compatibility

Re: [openstack-dev] [TripleO] Proposing Sergey (Sagi) Shnaidman for core on tripleo-ci

On 24.1.2017 18:03, Juan Antonio Osorio wrote: Sagi (sshnaidm on IRC) has done significant work in TripleO CI (both on the current CI solution and in getting tripleo-quickstart jobs for it); So I would like to propose him as part of the TripleO CI core team. +1 I think he'll make a great

Re: [openstack-dev] [tripleo] Update TripleO core members

On 23.1.2017 20:03, Emilien Macchi wrote: Greeting folks, I would like to propose some changes in our core members: - Remove Jay Dobies who has not been active in TripleO for a while (thanks Jay for your hard work!). - Add Flavio Percoco core on tripleo-common and tripleo-heat-templates docker

Re: [openstack-dev] [tripleo] Proposing Honza Pokorny core on tripleo-ui

On 24.1.2017 14:52, Emilien Macchi wrote: I have been discussed with TripleO UI core reviewers and it's pretty clear Honza's work has been valuable so we can propose him part of Tripleo UI core team. His quality of code and reviews make him a good candidate and it would also help the other 2

Re: [openstack-dev] [aodh][vitrage] Aodh generic alarms

On Tue, Jan 24 2017, gordon chung wrote: > you mean, keep alarm history in aodh and also in panko if needed? i'm ok > with that. Yeah, IIRC there's an expirer in Aodh for alarm history based on TTL – that's enough. That should probably be replaced with just a hard limit on the number of history

[openstack-dev] [openstack-ansible] Live migration issue

Hi osa team, i ‘ve got live migration issue in one direction but not in other. I deploy openstack with OSA, ubuntu trusty, stable/newton branch, 14.0.5 tag. My 2 compute node are same host type and have nova-compute and cinder-volume (our ceph cluster as backend) services. No problem to live

  1   2   >