Re: [openstack-dev] [charms] ceilometer metering and event time-to-live defaults

On Tue, Jan 03 2017, James Page wrote: Hi James, > In the current ceilometer charms, we retain all ceilometer data > indefinitely; the TTL can be overridden by users using configuration > options, but to me it feels like maybe retaining all data forever by > default is a trip hazard to users,

[openstack-dev] [all][QA][goals] Proposed Pike Goal Split Out Tempest Plugins

Hi Everyone, I pushed out a proposed OpenStack-wide goal for the Pike cycle to split all tempest plugins into separate repos: https://review.openstack.org/369749 At a high level all that is being proposed is that we split out any tempest plugins that are bundled in a service repo into a

Re: [openstack-dev] [keystone] Feedback for upcoming user survey questionnaire

"What were you trying to accomplish with keystone but failed" "What functionality in keystone did you try to use but it wasn't good enough" "In your opinion, what in keystone requires most attention" with choices "federation", "performance", "policy", "backend support" and some other options. On

[openstack-dev] [tripleo] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

Greetings All, Folks have been diligently working on the blueprint[1] to prepare TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for their transition into TripleO-CI. Presently, our aim is to begin the actual transition to OOOQ on 4-Feb-2017. We are tracking our work on the

[openstack-dev] [tripleo][ci] TripleO-Quickstart Transition to TripleO-CI Update and Invite:

adding [ci] to the subject. On Tue, Jan 3, 2017 at 4:04 PM, Harry Rybacki wrote: > Greetings All, > > Folks have been diligently working on the blueprint[1] to prepare > TripleO-Quickstart (OOOQ)[2] and TripleO-Quickstart-Extras[3] for > their transition into TripleO-CI.

Re: [openstack-dev] [Nova] python 3 tests hate my exception handling

I had a quick poke at this, and came to the same conclusion as Tim - that the problem was the from_response function. Getting rid of that allows the code to run under python3, but with the possibility of missing some of the exceptions from keystoneauth1.exceptions.http.__all__ . To make sure

Re: [openstack-dev] [Nova] python 3 tests hate my exception handling

On Jan 3, 2017 19:29, "Matt Riedemann" wrote: On 1/3/2017 8:48 PM, Michael Still wrote: > So... > > Our python3 tests hate [1] my exception handling for continued > vendordata implementation [2]. > > Basically, it goes a bit like this -- I need to move from using

Re: [openstack-dev] [neutron-lbaas][octavia]

I would like to emphasize the importance of this issue. Currently, all te LBaaS/Octavia gates are up on running (touch wood). Nevertheless, this bug will become more apparent (aka broken gates) in the next release of tempest (if we don't merge this fix beforehand). The reason is that the issue

[openstack-dev] [charms] bug day this thursday

Hi All Just a quick reminder that this Thursday (5th January) is our first bug day for charms of the year. Objective is to blast through the un-triaged bug backlog assigning some initial priorities and then fixup as many bugs as possible! Please co-ordinate via #openstack-charms so we don't all

[openstack-dev] [nova]openstack kvm external snapshot

As a result of the need to work, we need to modify the snapshot of the openstack to external snapshot, any suggestions is ok on how to achive.__ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

[openstack-dev] [neutron-lbaas][octavia]

When running neutron_lbaas scenarios tests with the latest tempest version we fail because of https://bugs.launchpad.net/octavia/+bug/1649083. I would like if anyone can go over the patch that fixes the problem and merge it, so our automation will succeed. The patch is

[openstack-dev] [charms] ceilometer metering and event time-to-live defaults

Hi All In the current ceilometer charms, we retain all ceilometer data indefinitely; the TTL can be overridden by users using configuration options, but to me it feels like maybe retaining all data forever by default is a trip hazard to users, and the actions required to backout of a full DB for

Re: [openstack-dev] [glance] question for OpenStack User Survey

On Thu, Dec 22, 2016 at 11:05 PM, Brian Rosmaita wrote: > Glancers, > > We have the opportunity to submit one question for the upcoming User > Survey, which launches on or before February 1. We'd receive responses > in advance of the February PTG, so this would be a

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

Hi, a comment about 'report as full' vs 'remove from inventory' On Mon, Jan 2, 2017 at 7:53 PM, Jay Pipes wrote: > Great questions, Vlad. Comments inline. > > On 12/30/2016 11:40 AM, Vladyslav Drok wrote: > >> Hi all! >> >> There is a long standing problem of resources

[openstack-dev] 答复: Your confirmation is required to join the OpenStack-dev mailing list

confirm 036e4a8c73e7f43ee135e0c2ac4c97c3f06e466d __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [charms] ceilometer metering and event time-to-live defaults

Hi Julien On Tue, 3 Jan 2017 at 09:17 Julien Danjou wrote: > > In the current ceilometer charms, we retain all ceilometer data > > indefinitely; the TTL can be overridden by users using configuration > > options, but to me it feels like maybe retaining all data forever by >

[openstack-dev] [telemetry] Shaping up Gnocchi 3.1

Hi folks, I'd like to push Gnocchi 3.1 pretty soon now. Here are the patches that I think we should merge before doing so, so this is the main patches (and their dependencies!) that should be reviewed in priority and ASAP: - Storage/incoming split https://review.openstack.org/#/c/402341 -

[openstack-dev] ovsdpdk mitaka

Hello Folks,, I am a learner in openstack to understand the cloud computing. Here, I am attempting to install a networking-ovs-dpdk-agent in openstack mitaka release on controller and compute node setup with ubuntu 16.04. Could you please help me what steps i need to follow to bring ovspdk up in

[openstack-dev] [storlets] No IRC meeting today

Dear Storleters, First of all, happy new year! I apologise by this late notice, but I got totally confused about the times and did not show up. Since things have been slow in the past couple of weeks, I hope no harm done. Please ping on IRC if you want to discuss anything. Apologies! Eran

Re: [openstack-dev] [neutron] [classifier] No Common Classifier / Classification Framework meeting

Hi all, Likewise, no meeting today. The next meeting will be on January 17th. Best regards, Igor. From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Tuesday, December 20, 2016 12:21 AM To: OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger wrote: > On 01/03/2017 04:01 AM, Anne Gentle wrote: > > [...] > > Doug, I think the include in Sphinx can be a raw txt file? Then we get > > the best of both worlds - rendered on both docs.openstack.org > >

Re: [openstack-dev] [neutron-lbaas][octavia]

In my opinion this patch should be changed. We should start using project_id instead of still keeping tenant_id property. All occurences of project_id in [1] should be fixed. Lubosz [1] neutron_lbaas/tests/tempest/v2/scenario/base.py From: Nir Magnezi Reply-To: "OpenStack

Re: [openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

Hey Vdrok, some comments inline. > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok wrote: > > Hi all! > > There is a long standing problem of resources reporting in ironic virt > driver. It's described in a couple of bugs I've found - [0], [1]. Switching > to placement API

Re: [openstack-dev] [magnum] Managing cluster drivers as individual distro packages

Team, We discussed this in today’s team meeting: http://eavesdrop.openstack.org/meetings/containers/2017/containers.2017-01-03-16.00.html Our consensus was to start iterating on this in-tree and break it out later into a separate repo once we have reasonably mature drivers, and/or further

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

Excerpts from Anne Gentle's message of 2017-01-03 10:26:28 -0600: > On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger wrote: > > > On 01/03/2017 04:01 AM, Anne Gentle wrote: > > > [...] > > > Doug, I think the include in Sphinx can be a raw txt file? Then we get > > > the best of

Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment

On 01/02/2017 09:06 PM, joehuang wrote: Hello, Currently only one region is supported in devstack-gate, there are lots of projects providing multi-region involved features, for example, heat multi-region, tacker multi-vim, shadow multi-cloud, tricircle networking across multi-region, kingbird

[openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific question on the next User Survey?

(Happy new year folks!) Forwarding Heidi's email to TripleO folks, so anyone can contribute to it. Feel free to propose questions on: https://etherpad.openstack.org/p/tripleo-user-survey-2017 The question with the more voting, will be proposed to the survey. Please take 2 min and help on

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

Excerpts from Andreas Jaeger's message of 2017-01-03 07:04:51 +0100: > On 01/03/2017 04:01 AM, Anne Gentle wrote: > > [...] > > Doug, I think the include in Sphinx can be a raw txt file? Then we get > > the best of both worlds - rendered on both docs.openstack.org > >

[openstack-dev] [nova] Nova API sub-team meeting

Happy new year! Start Nova API meeting again. The meeting is being held Wednesday UTC1300 and irc channel is #openstack-meeting-4. The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. Thanks

[openstack-dev] [MassivelyDistributed] Next meeting - Tomorrow 15:00 UTC

Dear all, Let me remind you that Massively Distributed Clouds WG meeting is scheduled tomorrow afternoon (15:00 UTC time) Agenda is available at : https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017(line 23). Feel free to complete it. All the best for 2017! ad_rien_

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On Tue, Jan 3, 2017 at 10:47 AM, Doug Hellmann wrote: > Excerpts from Anne Gentle's message of 2017-01-03 10:26:28 -0600: > > On Tue, Jan 3, 2017 at 12:04 AM, Andreas Jaeger wrote: > > > > > On 01/03/2017 04:01 AM, Anne Gentle wrote: > > > > [...] > > > >

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

On 2 Jan 2017, at 13:06, Davanum Srinivas wrote: > Folks, > > Short Story : > [1] has merged in devstack, it adds support for a python 3.5 based > up/down devstack test that just starts services and brings them down. > see [2] for a test run. > > Need help from swift folks: > Swift still needs

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote: > Hi Sean, > > I assume you're talking about OpenStack-Ansible (was OS-A-D before moving > to the OpenStack namespace), if not, feel free to ignore my response! Right. > This is actually something we're working on - we have in role testing for > some key OpenStack services

Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment

I don't like how it's adding more conditionals and complexity to an already fairly complex shell script. I've commented as such on the review. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment

Jay Pipes wrote: > I think it's a good idea to have multi-region testing in the gate, yes. How > does the existing federated Keystone functionality get tested in the gate? > Perhaps that might be an approach to copy? Just throwing out an idea here; > I'm actually not familiar with this part of the

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

Hi Sean, > OK - is this a job in Zuul ? Where can I find more information? > They are Zuul jobs, and are currently non-voting (but should be passing - we're waiting to ensure the tests are reliably passing before moving to voting). The test is essentially: Deploy infra for testing Deploy

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

On 01/03/2017 05:59 PM, Anne Gentle wrote: > > What happens is you get a special notification and link to > CONTRIBUTING.txt (or rst, but only after comparing branches) as in this > screenshot: > > https://postimg.org/image/wple5yudr/ > > But, based on testing, it's fine to keep what we have

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800: > > On 2 Jan 2017, at 13:06, Davanum Srinivas wrote: > > > Folks, > > > > Short Story : > > [1] has merged in devstack, it adds support for a python 3.5 based > > up/down devstack test that just starts services and brings them

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote: > Hi Sean, > > > > OK - is this a job in Zuul ? Where can I find more information? > > > The test is essentially: > > Deploy infra for testing > Deploy other required services > Deploy "stable/newton" version of project_name > Run "master" version of project_name > Run tests

Re: [openstack-dev] [all] Adding CONTRIBUTING.rst files to projects

Excerpts from Andreas Jaeger's message of 2017-01-03 19:29:25 +0100: > On 01/03/2017 05:59 PM, Anne Gentle wrote: > > > > What happens is you get a special notification and link to > > CONTRIBUTING.txt (or rst, but only after comparing branches) as in this > > screenshot: > > > >

Re: [openstack-dev] [nova] Outlook on Ocata blueprints

Hi Matt. The following blueprint has been approved for ocata, but it is not in "nova-ocata-feature-freeze" etherpad. * https://blueprints.launchpad.net/nova/+spec/cold-migration-with-target-ocata * https://review.openstack.org/#/c/334725/ (spec) The blueprint's definition is "Approved", but

Re: [openstack-dev] [neutron][ml2] Mechanism drivers ! OpenvSwich or Linuxbridge or both of them?

Zhi, Selection of driver is deployment dependent. You could run or more ML2 drivers simultaneous depending upon your deployment. Hierarchical Port Binding (HPB) facilitates multi-segmented L2 networks where the scope of the Segmentation ID is local to a given segment. For example - if you want

[openstack-dev] [ironic] Policy for deprecating metric names

Hi all, Recently, Ruby found a patch that modifies the name of a metric emitted by ironic. [0] After some IRC discussion, we realized that there is no real deprecation policy regarding changing metric names. [1] For anyone not familiar with this feature, ironic has the capability to emit various

[openstack-dev] [tripleo] quick reminder on review policy

I've noticed some TripleO core reviewers self approving patch without respecting our review policy, specially in tripleo-quickstart. Here are some quick reminder: http://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html#single-2-approvals

Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment

Not found any gate/check test for federated KeyStone job yet, this also makes me confused that such a feature was not tested in gate/check job, or I am missing something. So I have to build the multi-region job based on the guide

Re: [openstack-dev] [Neutron][networking-*] Attention for upcoming refactoring

I see this changes a function's argument types without changing the function's name - for instance, in the proposed networking-cisco change, https://review.openstack.org/#/c/409045/ . This makes it hard to detect that there's been a change and react accordingly. What's the recommended way to

Re: [openstack-dev] [infra][devstack-gate][all]support multi-region gate environment

If you run the multi-region offline(manually) with devstack, it works according to the guide http://docs.openstack.org/developer/devstack/configuration.html#multi-region-setup. That's the script from line 551~567 https://review.openstack.org/#/c/412777/2/devstack-vm-gate.sh Unfortunately

Re: [openstack-dev] [nova] Outlook on Ocata blueprints

Hi Matt, In Not started / blocked group in https://etherpad.openstack.org/p/nova-ocata-feature-freeze : https://blueprints.launchpad.net/nova/+spec/inject-nmi-ironic (Tang Chen) No Nova code changes yet, several Ironic patches outstanding, so probably not going to happen for Nova in

Re: [openstack-dev] [Nova] python 3 tests hate my exception handling

On 1/3/2017 8:48 PM, Michael Still wrote: So... Our python3 tests hate [1] my exception handling for continued vendordata implementation [2]. Basically, it goes a bit like this -- I need to move from using requests to keystoneauth1 for external vendordata requests. This is because we're adding

Re: [openstack-dev] [nova] Outlook on Ocata blueprints

On 1/3/2017 6:03 PM, Takashi Natsume wrote: Hi Matt. The following blueprint has been approved for ocata, but it is not in "nova-ocata-feature-freeze" etherpad. * https://blueprints.launchpad.net/nova/+spec/cold-migration-with-target-ocata * https://review.openstack.org/#/c/334725/ (spec)

[openstack-dev] [Nova] python 3 tests hate my exception handling

So... Our python3 tests hate [1] my exception handling for continued vendordata implementation [2]. Basically, it goes a bit like this -- I need to move from using requests to keystoneauth1 for external vendordata requests. This is because we're adding support for sending keystone headers with

Re: [openstack-dev] [Nova] python 3 tests hate my exception handling

Looks like keystoneauth1.exceptions.http.__all__ includes a from_response function. Maybe add a if isinstance(..., BaseException) before appending? Tim > On Jan 3, 2017, at 6:48 PM, Michael Still wrote: > > So... > > Our python3 tests hate [1] my exception handling for

[openstack-dev] Planning for the Pike PTG

I haven't been living under a rock but I'm not aware of any major announcements regarding session planning for the PTG - has that happened somewhere and I'm just in the dark? I'm mostly wondering about the Monday and Tuesday cross-project sessions - are those time-boxed sessions like at the

[openstack-dev] [kolla][kolla-kubernetes] microservices api status

I was asked to brief everyone with where we were at with the kolla-kubernetes microservices api. Config of the Kubernetes objects (not talking about openstack config files) is done through Helm values as all good Helm packages do. Defaults come from the Helm packages values.yaml file (1) and

[openstack-dev] [monasca]Monasca event handling capabilities

Hello, Please excuse me if i asked this question on wrong mailing list. I have few queries related to Monasca. 1) How do Monasca collects events releases by other openstack services like Nova and Cinder? 2) Can monasca collects the metrics from Neutron and other SDN controllers? please guide

[openstack-dev] [nova] Planning for the Pike PTG

Not to be confused with this other thread [1], I've started an etherpad [2] for people to start throwing ideas/topics for the upcoming Pike PTG which is February 20-24 in Atlanta. Things are pretty early yet since we're in the thick of Ocata, but if you have things you want to make sure we

[openstack-dev] [Vitrage] vitrage tempest job config

Hi all, I didn't find any vitrage project jenkins jobs registered in zuul/layout.yaml. Where does all the jobs configed?Thanks~ BR, dwj__ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

> > > Ah OK I see now. > > I guess what I'm driving at, is how do we get automated coverage for the > full end-to-end upgrade, so that issues[1] that I uncovered during manual > testing start getting uncovered by automation? > > [1]: https://review.openstack.org/#/c/400847/ Completely agree, the

Re: [openstack-dev] [swg][tc] An attempt to clarify/discuss: what exactly is the Stewardship Working Group, anyhow?

On 8 December 2016 at 15:33, Thierry Carrez wrote: > Colette Alexander wrote: >> [...] >> What are the sorts of things you'd like to see tackled? > > John Garbutt recently proposed that the TC works on defining visions for > itself[1] and OpenStack in general[2] and started

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

On 3 Jan 2017, at 10:38, Doug Hellmann wrote: > Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800: >> >> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote: >> >>> Folks, >>> >>> Short Story : >>> [1] has merged in devstack, it adds support for a python 3.5 based >>> up/down

[openstack-dev] [oslo] Not running for Oslo PTL for Pike

Hi Oslo folks (and others), Happy new year! After serving for about a year I think it's a good opportunity for myself to let another qualified individual run for Oslo PTL (seems common to only go for two terms and hand-off to another). So I just wanted to let folks know that I will be doing

Re: [openstack-dev] [tripleo] Adding a LateServices ResourceChain

On Fri, Dec 23, 2016 at 02:21:00PM +, Steven Hardy wrote: > I commented on the bug, I'm not sure about this as it seems to overlap with > our service_config_settings interface, which IIRC landed slightly after > your previous patches for opstools things, and potentially provides a > cleaner

Re: [openstack-dev] [os-ansible-deployment] Periodic job in infra to test upgrades?

Andy McCrae wrote: > Completely agree, the end goal is to have the full end-to-end testing in > the openstack-ansible repository, along with the individual repo tests. > We have an experimental job setup in > project-config: > (gate-openstack-ansible-openstack-ansible-upgrade-ubuntu-xenial-nv) >