Re: [openstack-dev] [Fuel][Nailgun] Random failures in unit tests

FakeUI, which is based on fake threads, is obviously needed for development purposes. Ideally we need to refactor our integration tests, so that we don't run whole pipeline in every test. To start, I suggest that we switch from threads to synchronous runs of test cases (while keeping threads for fa

Re: [openstack-dev] [Sahara][QA] Notes about the move of the Sahara Tempest API test to sahara-tests

Hi, Luigi! Thanks for this short spec :) Changes looking good for me, and I think Sahara-team can help with pushing this changes to sahara-tests repo. But I have a question: why we need to use detached branch for it? And then we have the next problem "Temporarily exclude a specific branch from th

Re: [openstack-dev] [all] Newton Design Summit - Proposed slot allocation

Emilien Macchi wrote: On Thu, Mar 17, 2016 at 1:29 PM, Thierry Carrez wrote: Emilien Macchi wrote: On Thu, Mar 17, 2016 at 11:43 AM, Kirill Zaitsev wrote: Is it too late to ask for a half-day Contributors Meetup for murano? We had an extremely successful contributors meetup in Tokyo and I

Re: [openstack-dev] [tc][ec2-api] EC2 API Future

Thank you Randy, you've summed up what I explained in the other thread. Yes I promise to keep up a good work as EC2 PTL in the next cycle if I'm appointed. Best regards, Alex Levine On 3/21/16 2:07 AM, Bias, Randy wrote: Hello, First of all, let me apologize for answering on Alex Lev

Re: [openstack-dev] [stable] Proposing Tony Breeds for stable-maint-core

Matt Riedemann wrote: I'd like to propose tonyb for stable-maint-core. Tony is pretty much my day to day guy on stable, he's generally in every stable team meeting (which is not attended well so I appreciate it), and he's as proactive as ever on staying on top of gate issues when they come up, so

[openstack-dev] [neutron] [sr-iov] Status of physical_device_mappings

Hey OpenStackers, I’ve recently found out, that changing of use neutron sriov-agent in Mitaka from optional to required[1] makes a kind of regression. Before Mitaka, there was possible to use any number of NICs with one Neutron physnet just by specifying pci_passthrough_whitelist in nova: [

[openstack-dev] [Bareon] Weekly update

Hi, here is a weekly update from Bareon team. 1. Extensions testing procedure in Fuel (required for Bareon integration). 1.1. Spec is still in progress [0]. 1.2. Email was sent [1] to figure out the best way to do it in OpenStack Infra, we would appreciate for any help on that. 2. Bareon dynamic

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

Doug Hellmann wrote: I won't be able to make the TC meeting this week because of travel, so I wanted to lay out my thoughts on the three PTL-less projects based on the outcome of the recent election (EC2-API, Winstackers, and Stable Maintenance). [...] First of all, I think we need to recognize

Re: [openstack-dev] [neutron] BGP Dynamic Routing Development Going Forward

Hi All, I would like to reopen this mail tread for 'N' release. It's really great that we are able to ship 'BGP Dynamic Routing' functionality as part of Mitaka. Thanks to everyone who has contributed and helped in making this a reality ;) For 'N' cycle, couple of RFE's [1] are already being line

Re: [openstack-dev] [TripleO] propose trown for core

On 20 March 2016 at 18:32, Dan Prince wrote: > I'd like to propose that we add John Trowbridge to the TripleO core > review team. John has become one of the goto guys in helping to chase > down upstream trunk chasing issues. He has contributed a lot to helping > keep general CI issues running and

Re: [openstack-dev] [TripleO] propose EmilienM for core

On 20 March 2016 at 18:22, Dan Prince wrote: > I'd like to propose that we add Emilien Macchi to the TripleO core > review team. Emilien has been getting more involved with TripleO during > this last release. In addition to help with various Puppet things he > also has experience in building Open

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

On 03/21/2016 07:11 AM, Doug Wiegley wrote: > >> On Mar 18, 2016, at 4:01 AM, Ihar Hrachyshka wrote: >> >> Hi all, >> >> Just giving my fellows an update from the event where we gathered our >> upgrades subteam to plan for Newton and do some coding. >> >> == >> >> We had folks from multiple co

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

I'm in general agreement here. The EC2 team is new to the process side, and is a small team. +1 for moving forward with Alex here. I'm +1 on Tony for Stable Maint. Though I also think that we should rollback any misgivings about election officials running for PTL slots. Of our 40 races only 7 (?)

Re: [openstack-dev] [TripleO] propose trown for core

On Sun, Mar 20, 2016 at 02:32:27PM -0400, Dan Prince wrote: > I'd like to propose that we add John Trowbridge to the TripleO core > review team. John has become one of the goto guys in helping to chase > down upstream trunk chasing issues. He has contributed a lot to helping > keep general CI issue

Re: [openstack-dev] [TripleO] propose EmilienM for core

On Sun, Mar 20, 2016 at 02:22:49PM -0400, Dan Prince wrote: > I'd like to propose that we add Emilien Macchi to the TripleO core > review team. Emilien has been getting more involved with TripleO during > this last release. In addition to help with various Puppet things he > also has experience in

Re: [openstack-dev] [all][infra][ptls] tagging reviews, making tags searchable

> From: Flavio Percoco > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/18/2016 09:04 PM > Subject: Re: [openstack-dev] [all][infra][ptls] tagging reviews, > making tags searchable > > On 18/03/16 14:15 +, Amrith Kumar wrote: > >As we were working through r

[openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

Hi, I was doing another pass on this spec, to see if we could leverage it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I have a question [1] I guess I'm just missing some detail, but looking at the 2nd scenario, why wouldn't availability zones allow the same exactly if we

Re: [openstack-dev] [all][infra][ptls] tagging reviews, making tags searchable

On 03/19/2016 05:51 PM, Jeremy Stanley wrote: > Rossella Sblendido was working on a similar solution[1] for Neutron > reviews, so this seems to be a popular desire across many projects. > The rough consensus[2] in Infra was in favor of a CI job to perform > the appropriate analysis to generate th

Re: [openstack-dev] [TripleO] propose EmilienM for core

On 20 March 2016 at 18:22, Dan Prince wrote: > I'd like to propose that we add Emilien Macchi to the TripleO core > review team. Emilien has been getting more involved with TripleO during > this last release. In addition to help with various Puppet things he > also has experience in building OpenS

Re: [openstack-dev] [TripleO] propose trown for core

On 20 March 2016 at 18:32, Dan Prince wrote: > I'd like to propose that we add John Trowbridge to the TripleO core > review team. John has become one of the goto guys in helping to chase > down upstream trunk chasing issues. He has contributed a lot to helping > keep general CI issues running and

Re: [openstack-dev] [new-project][gate]devstack-plugin-additional-pkg-repos

> From: Tony Breeds > To: OpenStack Development Mailing List > Date: 03/18/2016 04:57 AM > Subject: [openstack-dev] [new-project][gate] devstack-plugin- > additional-pkg-repos > > Hi All, > I just wanted to update everyone on a new devstack-plugin that allows us to > install alternate vers

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Fri, Mar 18, 2016 at 01:27:33PM +, arkady_kanev...@dell.com wrote: >Emilien, > >Agree on the rant. But not clear on concrete proposal to fix it. > >Spend more time “fixing” CI and use Tempest as a gate is a bit wage. > >Unless we test known working version of each project

Re: [openstack-dev] [Sahara][QA] Notes about the move of the Sahara Tempest API test to sahara-tests

On Monday 21 of March 2016 10:50:30 Evgeny Sikachev wrote: > Hi, Luigi! > > Thanks for this short spec :) > Changes looking good for me, and I think Sahara-team can help with pushing > this changes to sahara-tests repo. > > But I have a question: why we need to use detached branch for it? A bran

[openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

Hello all, the tests that we run on the gate for Neutron take pretty long (longer than one hour). I think we can improve that and make better use of the resources. Here are some ideas that came up when Ihar and I discussed this topic during the sprint in Brno: 1) We have few jobs that are non-vot

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

Sean M. Collins wrote: Ihar Hrachyshka wrote: One thing that we discussed on the event is updating networking-guide with detailed description of the upgrade process for neutron. We already have some pieces scattered there [f.e. we have some coverage for neutron-db-manage tool] but it’s nothing

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

Rossella Sblendido wrote: > 2) multi-node jobs run for every patch set. Is that really what we want? > They take pretty long. We could move them to a periodic job. I would rather remove all the single-node jobs. Nova has been moving to multinode jobs for their gate (if I recall correctly my conve

[openstack-dev] [salt] Team meeting this Tuesday

Hi Saltstackers, A kind reminder for this week's #openstack-salt meeting. More on the agenda [1]. [1]. https://wiki.openstack.org/wiki/Meetings/openstack-salt Regards, Jay Clark Sr. OpenStack Deployment Engineer E: jason.t.cl...@hpe.com H: 919.341.4670 M: 919.345.11

[openstack-dev] [Fuel][Bareon][Ironic] The future of integration module

Hi, I would like to bring up discussion on Bareon [0] and Ironic integration and plans for the future. But first let me provide background information on the topic. Bareon is partitioning/provisioning system [1] which is based on Fuel-agent [2], currently it's in active development and will be us

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

Doug Wiegley wrote: What is the plan for out of tree objects derived from neutron, and out of tree projects that are using the current neutron objects? Specifically, the ones which *can’t* use the REST API, because they’re for something loaded directly into neutron-server (core plugins,

Re: [openstack-dev] [TripleO] propose EmilienM for core

On Sun, Mar 20, 2016 at 2:22 PM, Dan Prince wrote: > I'd like to propose that we add Emilien Macchi to the TripleO core > review team. Emilien has been getting more involved with TripleO during > this last release. In addition to help with various Puppet things he > also has experience in building

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

Ihar Hrachyshka wrote: > + to that. There is some general info on upgrade planning at: > > http://docs.openstack.org/openstack-ops/content/ch_ops_upgrades.html > > We probably want to expand it with service specific details. Agreed. However take note that URL is the product of the old docbook s

Re: [openstack-dev] [neutron] report from Brno code sprint, Mar 14-16

Doug Wiegley wrote: Is our live upgrade strategy going to be labeled “reference only”? Not really. But since a typical neutron setup contains of components that belong to different subprojects and repos, the assumption would be that you will need every component hooked into neutron-server

Re: [openstack-dev] [TripleO] propose trown for core

On Sun, Mar 20, 2016 at 2:32 PM, Dan Prince wrote: > I'd like to propose that we add John Trowbridge to the TripleO core > review team. John has become one of the goto guys in helping to chase > down upstream trunk chasing issues. He has contributed a lot to helping > keep general CI issues runnin

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

Sean M. Collins wrote: Rossella Sblendido wrote: 2) multi-node jobs run for every patch set. Is that really what we want? They take pretty long. We could move them to a periodic job. I would rather remove all the single-node jobs. Nova has been moving to multinode jobs for their gate (if I r

[openstack-dev] [neutron][sriov] Status of physical_device_mappings

Hey OpenStackers, (sorry, forgot a tag:( ) I’ve recently found out, that changing of use neutron sriov-agent in Mitaka from optional to required[1] makes a kind of regression. Before Mitaka, there was possible to use any number of NICs with one Neutron physnet just by specifying pci_passthrough

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

>> On Mar 20, 2016, at 9:50 PM, Tony Breeds wrote: >> >> On Sun, Mar 20, 2016 at 12:48:43PM -0400, Doug Hellmann wrote: >> I won't be able to make the TC meeting this week because of travel, >> so I wanted to lay out my thoughts on the three PTL-less projects >> based on the outcome of the rece

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

> On Mar 21, 2016, at 5:33 AM, Thierry Carrez wrote: > > Doug Hellmann wrote: >> I won't be able to make the TC meeting this week because of travel, >> so I wanted to lay out my thoughts on the three PTL-less projects >> based on the outcome of the recent election (EC2-API, Winstackers, >> and

[openstack-dev] [Infra] Meeting Tuesday March 22nd at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday March 22nd, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting Anyone is welcome to to add agenda i

Re: [openstack-dev] [tripleo] becoming third party CI

On 17 March 2016 at 16:59, Ben Nemec wrote: > On 03/10/2016 05:24 PM, Jeremy Stanley wrote: >> On 2016-03-10 16:09:44 -0500 (-0500), Dan Prince wrote: >>> This seems to be the week people want to pile it on TripleO. Talking >>> about upstream is great but I suppose I'd rather debate major changes

[openstack-dev] [Fuel][plugins] stable/mitaka branches for plugins

Hey fuelers, We’re getting ready for Mitaka SCF in all things Fuel and plugins are currently a somewhat grey area. So I’d like to discuss which plugins should have stable/mitaka branches. We’re currently testing 3 plugins as a part of Swarm testing suite, so at least these 3 look like hard cand

Re: [openstack-dev] [stable] Proposing Tony Breeds for stable-maint-core

On 18/03/16 15:11 -0500, Matt Riedemann wrote: I'd like to propose tonyb for stable-maint-core. Tony is pretty much my day to day guy on stable, he's generally in every stable team meeting (which is not attended well so I appreciate it), and he's as proactive as ever on staying on top of gate i

[openstack-dev] [mistral] Team meeting reminder - 03/21/2006

Hi, This is a reminder that we’ll have a teem meeting today at #openstack-meeting at 16.00 UTC. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) Open discussion Renat Akhmerov @ Mirantis Inc. ___

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

> Red Herring. We don't need HMAC. We need to make better use of the tools in > Rabbit. I'm curious what you mean by this. I'd like to know the lessons learned. > As for HMAC several years/releases ago, what was the issue (just wondering)? > Just to much load on controller nodes to do verificat

Re: [openstack-dev] [all] Maintaining httplib2 python library

Ian, Chris, You should see invites to join the httplib2 org on github. Thanks, Dims On Fri, Mar 18, 2016 at 3:04 PM, Ian Cordasco wrote: > > > -Original Message- > From: Cory Benfield > Reply: OpenStack Development Mailing List (not for usage questions) > > Date: March 18, 2016 at 13

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

The idea is to write python (or shell) script which will: > - clone all required repos (like fuel-web, extensions repos) using > probably zuul-cloner Doesn’t nodepool automatically do that? > - checkout to appropriate stable branches / will cherry-pick some > commit / stay on master As far a

Re: [openstack-dev] [tripleo] [puppet] move puppet-pacemaker

Hi, I've been working on it lately, mainly adding idempotency and beaker jobs to the openstack/puppet-pacemaker version. Such a merge would be great. I'm in for such project. Emilien Macchi writes: > On Fri, Mar 18, 2016 at 10:55 AM, Dmitry Ilyin wrote: >> Hello. >> >> I'm the author of fuel

[openstack-dev] [Fuel] [shotgun] New shotgun2 command: short-report

Hi, all Just wanted to inform you, that shotgun2 now has new command short-report, which allows you to receive shorter and cleaner output for attaching to bug description, sharing, etc. Usage: shotgun2 short-report Example output: http://paste.openstack.org/show/491256/ Regards, Volodymyr __

[openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

Hi, we have a big problem when using domain-specific configuration. The listing of all users is not supported by keystone when it's used[1][2]. What this means is that prefetch method in keystone_user won't work, or more specifically, instances method will fail. This poses a problem for the key

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Mon, Mar 21, 2016 at 6:57 AM, Steven Hardy wrote: > On Fri, Mar 18, 2016 at 01:27:33PM +, arkady_kanev...@dell.com wrote: >>Emilien, >> >>Agree on the rant. But not clear on concrete proposal to fix it. >> >>Spend more time “fixing” CI and use Tempest as a gate is a bit wage. >>

Re: [openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

Hi Athlan, thanks for attention of this problem. We have one more related change [1] and bug [2] for this problem, when we option 'domain_specific_drivers' is used. I would like to vote for 3) case. As I see it there are three ways to approach this: > - iterate over all domains and keep the sam

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Mon, Mar 21, 2016 at 09:41:42AM -0400, Emilien Macchi wrote: > On Mon, Mar 21, 2016 at 6:57 AM, Steven Hardy wrote: > > On Fri, Mar 18, 2016 at 01:27:33PM +, arkady_kanev...@dell.com wrote: > >>Emilien, > >> > >>Agree on the rant. But not clear on concrete proposal to fix it. > >> >

Re: [openstack-dev] [new-project][gate] devstack-plugin-additional-pkg-repos

Tony Breeds wrote: > Longer term TODO list: > 1) find a home in the big tent > 2) test all the things > 3) Use this for Neutron to test OVS > - Is there and existing package repo we can test on trusty? Fantastic work Tony, thank you for doing this. I look forward to seeing the OVS stuff that i

[openstack-dev] [nova] Prepping Mitaka RC2

Hi, We have created the Nova milestone for RC2: https://launchpad.net/nova/+milestone/mitaka-rc2 To make bugs appear there, you need to add the mitaka series and target RC2. Annoying LP permissions means this can only be done by a nova-driver, AFAIK. We will keep using the mitaka-rc-potential ta

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

Hi Roman, >> reasonable to just install it from PyPi (first we need to release Nailgun to PyPi) Yes there will be dependencies, but there should be a way to test core extensions (those which go to standard Fuel build) from master (or any other branch), so installing from pypi is not always an opt

Re: [openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

On 03/21/2016 06:22 AM, Miguel Angel Ajo Pelayo wrote: Hi, I was doing another pass on this spec, to see if we could leverage it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I have a question [1] I guess I'm just missing some detail, but looking at the 2nd scenario, wh

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Mon, Mar 21, 2016 at 9:59 AM, Steven Hardy wrote: > On Mon, Mar 21, 2016 at 09:41:42AM -0400, Emilien Macchi wrote: >> On Mon, Mar 21, 2016 at 6:57 AM, Steven Hardy wrote: >> > On Fri, Mar 18, 2016 at 01:27:33PM +, arkady_kanev...@dell.com wrote: >> >>Emilien, >> >> >> >>Agree on t

[openstack-dev] [puppet] weekly meeting #75

Hi, We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting4. https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack As usual, free free to bring topics in this etherpad: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322 We'll start discussing about the

Re: [openstack-dev] [TripleO] propose EmilienM for core

On 03/20/2016 02:22 PM, Dan Prince wrote: I'd like to propose that we add Emilien Macchi to the TripleO core review team. Emilien has been getting more involved with TripleO during this last release. In addition to help with various Puppet things he also has experience in building OpenStack ins

Re: [openstack-dev] [TripleO] propose trown for core

On 03/20/2016 02:32 PM, Dan Prince wrote: I'd like to propose that we add John Trowbridge to the TripleO core review team. John has become one of the goto guys in helping to chase down upstream trunk chasing issues. He has contributed a lot to helping keep general CI issues running and been inv

Re: [openstack-dev] [TripleO] propose trown for core

On Sun, Mar 20, 2016 at 8:32 PM, Dan Prince wrote: > I'd like to propose that we add John Trowbridge to the TripleO core > review team. John has become one of the goto guys in helping to chase > down upstream trunk chasing issues. He has contributed a lot to helping > keep general CI issues runni

Re: [openstack-dev] [Fuel] [shotgun] New shotgun2 command: short-report

On Mon, Mar 21, 2016 at 7:21 AM, Volodymyr Shypyguzov < vshypygu...@mirantis.com> wrote: > Hi, all > > Just wanted to inform you, that shotgun2 now has new command short-report, > which allows you to receive shorter and cleaner output for attaching to bug > description, sharing, etc. > > Usage: sh

Re: [openstack-dev] [nova][neutron] Routed networks / Generic Resource pools

On Mon, Mar 21, 2016 at 3:17 PM, Jay Pipes wrote: > On 03/21/2016 06:22 AM, Miguel Angel Ajo Pelayo wrote: >> >> Hi, >> >> I was doing another pass on this spec, to see if we could leverage >> it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I >> have a question [1] >> >>

[openstack-dev] [Openstack] Boot instance from volume via Horizon dashboard fails

Hi all, I'm not subscribed to this list, usually I'm just a (new) Openstack user, but I have a question regarding the Horizon dashboard respectively launching instances via dashboard. I have a Liberty deployment running on 1 controller and 2 compute nodes. I also deployed an external cinder

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

On 20/03/2016 5:58 PM, Joshua Harlow wrote: > On 03/20/2016 10:00 AM, Adam Young wrote: >> I started with a blog post here: >> >> http://adam.younglogic.com/2016/03/what-can-talk-to-what-on-the-openstack-message-broker/ >> >> >> >> and did a brief spike here: >> >> http://adam.younglogic.com/2016

Re: [openstack-dev] [tripleo] Contributing to TripleO is challenging

On Mon, Mar 21, 2016 at 10:19:47AM -0400, Emilien Macchi wrote: > On Mon, Mar 21, 2016 at 9:59 AM, Steven Hardy wrote: > > On Mon, Mar 21, 2016 at 09:41:42AM -0400, Emilien Macchi wrote: > >> On Mon, Mar 21, 2016 at 6:57 AM, Steven Hardy wrote: > >> > On Fri, Mar 18, 2016 at 01:27:33PM +, ark

[openstack-dev] [horizon] A big thanks to the Horizon team for their support (Django 1.9 support needed for Debian)

Hi there! The Horizon team really went out of their boundaries to help adding support for Django 1.9, which was required for the upload to Debian. Apart from Debian, no other distro needed the support just yet, but they made it happen on time, just after the RC1 (which is fine, I'm adding the patc

[openstack-dev] [Openstack] Boot instance from volume via Horizon dashboard fails

Hi all, I'm just a (new) Openstack user, not a developer, but I have a question regarding the Horizon dashboard respectively launching instances via dashboard. I have a Liberty deployment running on 1 controller and 2 compute nodes. I also deployed an external cinder-volume as a storage bac

Re: [openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

Denis Egorenko writes: > Hi Athlan, > > thanks for attention of this problem. We have one more related change > [1] and bug [2] > for this problem, when we option 'domain_specific_drivers' is used. > > I would like to vote for 3) case. > > As I see it there are three ways to approach this: >

Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

Akihiro, thank you for your effort with translation, this milestone sounds fine for murano-dashboard. On Sat, Mar 19, 2016 at 10:43 AM, Akihiro Motoki wrote: > Hi dashboard plugins team > (sahara-dashboard, trove-dashboard, magnum-ui, murano-dashboard) > > As Horizon i18n liaison, I would like

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

> On Mar 21, 2016, at 5:40 AM, Ihar Hrachyshka wrote: > > Sean M. Collins wrote: > >> Rossella Sblendido wrote: >>> 2) multi-node jobs run for every patch set. Is that really what we want? >>> They take pretty long. We could move them to a periodic job. >> >> I would rather remove all the sin

Re: [openstack-dev] [Openstack] Boot instance from volume via Horizon dashboard fails

On 16:01 Mar 21, Eugen Block wrote: > Hi all, > > I'm just a (new) Openstack user, not a developer, but I have a question > regarding the Horizon dashboard respectively launching instances via > dashboard. Hi Eugen! Welcome to the community! This mailing list is development focused and not our s

Re: [openstack-dev] Visa Invitation Letter doesn't contain attachment

On 03/20/2016 10:46 PM, Zhi Chang wrote: > hi, guys. > > I received Visa Invitation Letter a few days ago. But the letter doesn't > contain attachment. What should I do? > > > > > Thanks > Zhi Chang > > > > __ > O

Re: [openstack-dev] [puppet] Prefecting user and user_roles resources with domain-specific conf is failing.

> > The domain, at this stage won't be a problem to be concerned with, we > will have its value. The only thing to add, I think, would be some kind > of caching for keystone_user_role call to avoid repetition. This > shouldn't be hard to implement though. Well yes, we can create method in paren

Re: [openstack-dev] [Openstack] Boot instance from volume via Horizon dashboard fails

On 3/21/2016 10:31 AM, Mike Perez wrote: On 16:01 Mar 21, Eugen Block wrote: Hi all, I'm just a (new) Openstack user, not a developer, but I have a question regarding the Horizon dashboard respectively launching instances via dashboard. Hi Eugen! Welcome to the community! This mailing list

Re: [openstack-dev] [tripleo] becoming third party CI

On 03/21/2016 07:33 AM, Derek Higgins wrote: > On 17 March 2016 at 16:59, Ben Nemec wrote: >> On 03/10/2016 05:24 PM, Jeremy Stanley wrote: >>> On 2016-03-10 16:09:44 -0500 (-0500), Dan Prince wrote: This seems to be the week people want to pile it on TripleO. Talking about upstream is g

[openstack-dev] Somebody posted this on #openstack-meetng-4

I just noticed that somebody posted this on the above meeting channel. [23:22:31] Allah is doing [23:22:42] sun is not doing Allah is doing [23:22:42] *yamamoto* (~yamam...@i118-21-144-234.s30.a048.ap.plala.or.jp) left IRC (Remote host closed the connection) [23:22:54] moon is not doin

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

-Original Message- From: Adam Young Reply: OpenStack Development Mailing List (not for usage questions) Date: March 20, 2016 at 12:03:01 To: openstack-dev@lists.openstack.org Subject:  Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo?? > On 03/19/2016 11:3

[openstack-dev] [kolla] branching Mitaka March 21, 2016 (important note for CRs)

Hey folks, Typically all projects branch at rc1, but originally because we had a mountain of blueprints and bugs after mitaka-3 was released, I sent an email indicating we would branch at rc2. Unfortunately branching at rc2 is not a viable plan because we are gating the master code base of Ope

Re: [openstack-dev] [i18n][horizon][sahara][trove][magnum][murano] dashboard plugin release schedule

On 19/03/2016 17:47, Akihiro Motoki wrote: > Hi dashboard plugins team > (sahara-dashboard, trove-dashboard, magnum-ui, murano-dashboard) > There is also a designate-dashboard plugin - we have translation set up for Mitaka. We have string frozen as of RC1 - so if there is translations before RC2

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

Doug, Let me clarify a bit the situation. Before this February there wasn't such a project at all. EC2 API was a built-in part of nova so no dedicated PTL was required. The built-in part got removed and our project got promoted. We're a team of 3 developers which nevertheless are committed to

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

The Neutron RFE process [1] demands time-committment from various groups which I cannot give. A face-to-face discussion could be benefitial to come to a conclusion, so I proposed a session for the Newton summit at [2] (see section "RFEs: communication channel and process"). There won't be a big

Re: [openstack-dev] [stable] Proposing Tony Breeds for stable-maint-core

> On Mar 18, 2016, at 4:11 PM, Matt Riedemann > wrote: > > I'd like to propose tonyb for stable-maint-core. Tony is pretty much my day > to day guy on stable, he's generally in every stable team meeting (which is > not attended well so I appreciate it), and he's as proactive as ever on > st

Re: [openstack-dev] [networking-ovn][Neutron] OVN support for routed networks(plugin interface for host mapping)

On Thu, Mar 17, 2016 at 1:45 AM, Hong Hui Xiao wrote: > Hi Russell. > > Since the "ovn-bridge-mapping" will become accessible in OVN Southbound > DB, do you meant that neutron plugin can read those bridge mappings from > the OVN Southbound DB? I didn't think in that way because I thought > networ

Re: [openstack-dev] [tc][ec2-api] EC2 API Future

> On Mar 20, 2016, at 3:26 PM, Tim Bell wrote: > > > Doug, > > Given that the EC2 functionality is currently in use by at least 1/6th of > production clouds > (https://www.openstack.org/assets/survey/Public-User-Survey-Report.pdf page > 34), this is a worrying situation. I completely agre

Re: [openstack-dev] Somebody posted this on #openstack-meetng-4

On 03/21/2016 11:59 AM, Sukhdev Kapur wrote: > I just noticed that somebody posted this on the above meeting channel. Yes, that took place over the weekend and pleia2 removed that user. Should you see spam occur in irc channels please notify someone in #openstack-infra so they can address the is

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

On 21 March 2016 at 04:32, Sean M. Collins wrote: > Rossella Sblendido wrote: > > 2) multi-node jobs run for every patch set. Is that really what we want? > > They take pretty long. We could move them to a periodic job. > > I would rather remove all the single-node jobs. Nova has been moving to >

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

On 21 March 2016 at 04:15, Rossella Sblendido wrote: > Hello all, > > the tests that we run on the gate for Neutron take pretty long (longer > than one hour). I think we can improve that and make better use of the > resources. Here are some ideas that came up when Ihar and I discussed this topic

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

> On Mar 21, 2016, at 12:03 PM, Alexandre Levine > wrote: > > Doug, > > Let me clarify a bit the situation. > Before this February there wasn't such a project at all. EC2 API was a > built-in part of nova so no dedicated PTL was required. The built-in part got > removed and our project got p

[openstack-dev] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

Folks, We have been analyzing a bunch of random failures in Fuel tests and encountered several ones caused by detector raising errors occasionally [1]. After attempts to reproduce the same behavior have failed we’ve decided to run the same test suit on overloaded nodes. Those test-runs allowed

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

Does Oslo provide a consistent hashing library? I think a number of projects (swift [1] and ironic [2] for example) are using various implementations and Octavia may need to start using consistent hashing soon. [1] http://docs.openstack.org/developer/swift/ring.html [2] https://blueprints.launch

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

On 03/21/2016 12:33 PM, Doug Hellmann wrote: > >> On Mar 21, 2016, at 12:03 PM, Alexandre Levine >> wrote: >> >> Doug, >> >> Let me clarify a bit the situation. >> Before this February there wasn't such a project at all. EC2 API was a >> built-in part of nova so no dedicated PTL was required. T

Re: [openstack-dev] [oslo][all] What would you like changed/fixed/new in oslo??

> From: Joshua Harlow > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/20/2016 04:33 AM > Subject: [openstack-dev] [oslo][all] What would you like changed/ > fixed/new in oslo?? > > Howday all, > > Just to start some conversation for the next cycle, > > I want

Re: [openstack-dev] [all][infra][ptls] tagging reviews, making tags searchable

On Sat, Mar 19, 2016 at 04:51:14PM +, Jeremy Stanley wrote: > On 2016-03-19 02:28:48 + (+), Amrith Kumar wrote: > > Maybe we could collaborate and build something that'd work for > > multiple projects? Happy to help with this. It is clearly a > > problem that some projects seem to be fa

[openstack-dev] [swift] Hummingbird Roadmap

Hi all, I was wondering what the roadmap for Hummingbird is. Will development continue? Will support continue? Is it expected to reach feature parity or even replace the Python code? Thank you, Avishay -- *Avishay Traeger, PhD* *System Architect* Mobile: +972 54 447 1475 E-mail: avis...@stra

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

On 2016-03-21 06:14:25 -0400 (-0400), Sean Dague wrote: [...] > I'm +1 on Tony for Stable Maint. Though I also think that we > should rollback any misgivings about election officials running > for PTL slots. Of our 40 races only 7 (?) were actual elections. > Election officials are chosen well befo

Re: [openstack-dev] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

Hey Roman, Thank you for investigation. However, I think that changing 'deadlock_timeout' won't help us. According to PostgreSQL documentation [1], this option sets how frequently to check if there is a deadlock condition. So it won't fix deadlocks themselves. Thus I see no reason why we should c

Re: [openstack-dev] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

Roman, According to documentation [1] this setting is responsible for the amount of time to wait a lock to be released before trying to check if it is, in fact, a deadlock. This time just allows not to spend resources for unnecessary checks. If a lock is not a deadlock, this check will just skip i

Re: [openstack-dev] [tc][election][ec2-api][winstackers][stable] status of teams without PTL candidates

On 03/21/2016 01:06 PM, Jeremy Stanley wrote: > On 2016-03-21 06:14:25 -0400 (-0400), Sean Dague wrote: > [...] >> I'm +1 on Tony for Stable Maint. Though I also think that we >> should rollback any misgivings about election officials running >> for PTL slots. Of our 40 races only 7 (?) were actual

Re: [openstack-dev] [neutron] CI jobs take pretty long, can we improve that?

On Mon, Mar 21, 2016, at 09:32 AM, Armando M. wrote: > Do you have an a better insight of job runtimes vs jobs in other > projects? > Most of the time in the job runtime is actually spent setting the > infrastructure up, and I am not sure we can do anything about it, unless > we > take this with I

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

On 03/19/2016 11:10 AM, Monty Taylor wrote: > The patch looks good, but it conflicts with the > move-nova-jobs-to-db-macro and the "add debian jessie support for bindep > fallback" change. Rather than fighting the rebase fight, let's put a > brief hold on this (sorry, I know) and land it as soon as

  1   2   >