Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

On 18/11/14 18:46 +0100, Thierry Carrez wrote: Flavio Percoco wrote: On 18/11/14 11:42 +0100, Thierry Carrez wrote: With storyboard.openstack.org looming on the horizon, should such an effort be put on the back burner for now? I don't expect integrated projec

Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

On 18/11/14 10:58 -0800, Clint Byrum wrote: Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800: Greetings, Regardless of how big/small bugs backlog is for each project, I believe this is a common, annoying and difficult problem. At the oslo meeting today, we're talking about ho

[openstack-dev] Subject: Re: [Ironic] Proposing new meeting times

+1 for Option #2: alternate between Monday 1700 UTC && Tuesday 0500 UTC Wanyen On Tue, Nov 18, 2014 at 01:00:04AM +, Devananda van der Veen wrote: > Hi all, > > As discussed in Paris and at today's IRC meeting [1] we are going to be > alternating the time of the weekly IRC meetings to

Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

On 18/11/14 14:45 -0800, Joe Gordon wrote: On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum wrote: Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800: > Greetings, > > Regardless of how big/small bugs backlog is for each project, I > believe this is a common, anno

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Same question regarding QoS as a Service, once it will be approved. Should it belong to Advanced Services as well? -Original Message- From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] Sent: Wednesday, November 19, 2014 9:15 AM To: OpenStack Development Mailing List (not for usage qu

[openstack-dev] [Glance] Recall for previous iscsi backend BP

In the Previous BP [1], support for iscsi backend is introduced into glance. However, it was abandoned because of Cinder backend replacement. The reason is that all storage backend details should be hidden by cinder, not exposed to other projects. However, with more and more interest in "Converged

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Wednesday, November 19, 2014 12:54 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra. On Sun, Nov 16, 2014 at 5:31

Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

Hi It is a great idea. +1 On 19/11/2014 00:27, Vishvananda Ishaya wrote: It looks like this has not been reported so a bug would be great. It looks like it might be as easy as adding the NoMoreFixedIps exception to the list where FixedIpLimitExceeded is caught in nova/network/manager.py Vish

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On Tue, Nov 18, 2014 at 11:04 PM, henry hly wrote: > Is FWaas L2/3 or L4/7? > Thats a good question, and what has been asked here in the context of VPNaaS as well. Hence the proposed definition below avoids characterizing the advanced services project purely as L4-7 because that would not be accu

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Is FWaas L2/3 or L4/7? On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam wrote: > On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif wrote: >> I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS >> deals with L3 connectivity but belongs in advanced services. Where does >> E

Re: [openstack-dev] [Neutron] Should we clean resource first then do assert in test?

Correct, So, it's better to keep tests clean of de resource cleanups for readability purposes and easier maintenance. Sent from my Android phone using TouchDown (www.nitrodesk.com) -Original Message- From: Kevin Benton [blak...@gmail.com] Received: Wednesday, 19 Nov 2014, 5:18 To:

[openstack-dev] [nova] Do we need to add xml support for new API extensions on v2 API ?

Hi I saw we are removing v2 XML support proposed several days before For new api extensions, do we need to add it now and remove it later or only support JSON ? Thanks Best Regards! Kevin (Chen) Ji 纪 晨 Engineer, zVM Development, CSTL Notes: Chen CH Ji/China/IB

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

Hello Folks, Couple of slides/diagrams, I documented it for my understanding way back for havana release. Particularly slide no. 10 onward. https://docs.google.com/presentation/d/1ZPWKXN7dzXs9bX3Ref9fPDiia912zsHCHNMh_VSMhJs/edit#slide=id.p I am also committed to using zeromq as it's light-weight

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

I've just had a long discussion with #infra folk about the global-requirements thing, which deviated (quite naturally) into a discussion about packaging (and their thoughts were in line with where Radomir and I are heading). In their view, bower components don't need to be in global-requirements:

Re: [openstack-dev] [Neutron] Should we clean resource first then do assert in test?

It's basically a style argument at this point. All resources are destroyed at the DB level at the end of each test regardless of what happens.[1] 1. https://github.com/openstack/neutron/blob/33c60c18cc78fb558ab8464c007559e44100ebba/neutron/tests/unit/testlib_api.py#L74 On Tue, Nov 18, 2014 at 7:3

[openstack-dev] [Neutron] Should we clean resource first then do assert in test?

Hi, @Michali asked me a question about clean resource after assert seems not valid in a review . Should we clean resource before assert? Regards Wei Wang _

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif wrote: > I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS > deals with L3 connectivity but belongs in advanced services. Where does > Edge-VPN work belong? We need a broader definition for advanced services > area. > So

Re: [openstack-dev] [neutron] L2 gateway as a service

Hi, On 18 November 2014 16:22, Ian Wells wrote: > Sorry I'm a bit late to this, but that's what you get from being on > holiday... (Which is also why there are no new MTU and VLAN specs yet, but > I swear I'll get to them.) > Ah! I hope it was good at least :) > > On 17 November 2014 01:13,

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

On 2014/11/19 1:49, Eric Windisch wrote: I think for this cycle we really do need to focus on consolidating and testing the existing driver design and fixing up the biggest deficiency (1) before we consider moving forward with lots of new +1 1) Outbound messaging connection r

[openstack-dev] [Fuel] Duplicate bugs vs reopening unrelated bugs

Fuelers, I've added the following paragraph into Fuel's How to contribute Wiki page: https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Test_and_report_bugs "Before creating a new bug, it's always a good idea to check if a bug like that already exists in the project, and update an existing bu

Re: [openstack-dev] [Fuel] Waiting for Haproxy backends

On Wed, Nov 12, 2014 at 4:10 AM, Aleksandr Didenko wrote: > HI, > > in order to make sure some critical Haproxy backends are running (like mysql > or keystone) before proceeding with deployment, we use execs like [1] or > [2]. We used to do the API waiting in the puppet resource providers consumi

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

I agree with Paul as advanced services go beyond just L4-L7. Today, VPNaaS deals with L3 connectivity but belongs in advanced services. Where does Edge-VPN work belong? We need a broader definition for advanced services area. Thanks, —Hanif. From: "Paul Michali (pcm)" mailto:p...@cisco.com>>

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On 18 November 2014 15:33, Mark McClain wrote: > > > On Nov 18, 2014, at 5:45 PM, Doug Hellmann > wrote: > > > > There would not be a service or REST API associated with the Advanced > Services code base? Would the REST API to talk to those services be part of > the Neutron repository? > > > > D

Re: [openstack-dev] [nova] Wednesday Bug Day

If you haven't seen Tracy's bug triage page yet, here it is: http://54.201.139.117/nova-bugs.html -- dims On Tue, Nov 18, 2014 at 7:27 PM, Joe Gordon wrote: > Hi All, > > At the kilo nova meeting up in Paris, We had a lengthy discussion on better > bug management. One of the action items was to

[openstack-dev] [nova] Wednesday Bug Day

Hi All, At the kilo nova meeting up in Paris, We had a lengthy discussion on better bug management. One of the action items was to make every Wednesday a bug day nova in #openstack-nova [0]. So tomorrow will be our first attempt at "Bug Wednesday." One of the issues we found with previous bug me

Re: [openstack-dev] [Fuel] Waiting for Haproxy backends

Some comments inline On Tue, Nov 18, 2014 at 3:18 PM, Andrew Beekhof wrote: > Hi Everyone, > > I was reading the blueprints mentioned here and thought I'd take the > opportunity to introduce myself and ask a few questions. > For those that don't recognise my name, Pacemaker is my baby - so I tak

Re: [openstack-dev] [neutron] L2 gateway as a service

Sorry I'm a bit late to this, but that's what you get from being on holiday... (Which is also why there are no new MTU and VLAN specs yet, but I swear I'll get to them.) On 17 November 2014 01:13, Mathieu Rohon wrote: > Hi > > On Fri, Nov 14, 2014 at 6:26 PM, Armando M. wrote: > > Last Friday

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On Nov 18, 2014, at 6:36 PM, Armando M. wrote: > Mark, Kyle, > > What is the strategy for tracking the progress and all the details about this > initiative? Blueprint spec, wiki page, or something else? > > One thing I personally found useful about the spec approach adopted in [1], > was that

Re: [openstack-dev] [nova] v3 integrated tests taking a lot longer?

On 11/18/2014 5:48 PM, Matt Riedemann wrote: I just started noticing today that the v3 integrated api samples tests seem to be taking a lot longer than the other non-v3 integrated api samples tests. On my 4 VCPU, 4 GB RAM VM some of those tests are taking anywhere from 15-50+ seconds, while the

[openstack-dev] [nova] v3 integrated tests taking a lot longer?

I just started noticing today that the v3 integrated api samples tests seem to be taking a lot longer than the other non-v3 integrated api samples tests. On my 4 VCPU, 4 GB RAM VM some of those tests are taking anywhere from 15-50+ seconds, while the non-v3 tests are taking less than a second.

[openstack-dev] Dynamic Policy

There is a lot of discussion about policy. I've attempted to pull the majority of the work into a single document that explains the process in a step-by-step manner: http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ Its really long, so I won't bother reposting the whole article

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Mark, Kyle, What is the strategy for tracking the progress and all the details about this initiative? Blueprint spec, wiki page, or something else? One thing I personally found useful about the spec approach adopted in [1], was that we could quickly and effectively incorporate community feedback;

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

> On Nov 18, 2014, at 5:45 PM, Doug Hellmann wrote: > > There would not be a service or REST API associated with the Advanced > Services code base? Would the REST API to talk to those services be part of > the Neutron repository? > > Doug We had considered having a standalone REST service, b

Re: [openstack-dev] oslo.db 1.1.0 released

On 11/18/2014 10:17 AM, Victor Sergeyev wrote: Matt, As for race in Nova - it caused by deprecated is_backend_avail() function, which calls _ensure_backenv_available() method, which creates a SQLAlchemy engine and opens a test connection, but doesn't call engine.dispose(). Depending on Python

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

Hi, > so the specs repository would continue to be shared during the Kilo cycle. One of the reasons to split is that these two teams have different priorities and velocities. Wouldn’t that be easier to track/manage as separate launchpad projects and specs repos, irrespective of who is approvin

Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

It looks like this has not been reported so a bug would be great. It looks like it might be as easy as adding the NoMoreFixedIps exception to the list where FixedIpLimitExceeded is caught in nova/network/manager.py Vish On Nov 18, 2014, at 8:13 AM, Edgar Magana wrote: > Hello Community, > >

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

> > There would not be a service or REST API associated with the Advanced > Services code base? Would the REST API to talk to those services be part of > the Neutron repository? This is a good question. Also, I would love to have more details about the following point: - The Advance Service Lib

Re: [openstack-dev] [Fuel] Waiting for Haproxy backends

Hi Everyone, I was reading the blueprints mentioned here and thought I'd take the opportunity to introduce myself and ask a few questions. For those that don't recognise my name, Pacemaker is my baby - so I take a keen interest helping people have a good experience with it :) A couple of items

Re: [openstack-dev] [oslo] kilo graduation plans

On Wednesday, November 12, 2014 02:06:02 PM Doug Hellmann wrote: > During our “Graduation Schedule” summit session we worked through the list of > modules remaining the in the incubator. Our notes are in the etherpad [1], > but as part of the "Write it Down” theme for Oslo this cycle I am also >

[openstack-dev] [oslo] update your blueprints and specs

I have merged all of the specs that we agreed were ready for approval. Some needed blueprints created, so I did that too. If you have one of these specs, please look at the blueprint status and make sure that it is correct (especially if it should be “Needs Code Review” or “Blocked”). Also pleas

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

My name is already on the etherpad in the RPC section, but I'll reiterate here that I'm very interested in optimizing a lot of the expensive ongoing communication between the L2 agent and the server on the message bus. On Tue, Nov 18, 2014 at 9:12 AM, Carl Baldwin wrote: > At the recent summit,

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

On Sun, Nov 16, 2014 at 5:31 AM, Irena Berezovsky wrote: > Hi Steve, > Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal > node with Mellanox SR-IOV NIC. This job is reporting on neutron patches. > Currently API tests are executed. > The contact person for SRIOV CI job i

Re: [openstack-dev] [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

On Mon, Nov 17, 2014 at 1:29 PM, Ian Wells wrote: > On 12 November 2014 11:11, Steve Gordon wrote: > > NUMA >> >> >> We still need to identify some hardware to run third party CI for the >> NUMA-related work, and no doubt other things that will come up. It's >> expected that this will be an

Re: [openstack-dev] Dynamic VM Consolidation Agent as part of Nova

On Tue, Nov 18, 2014 at 7:40 AM, Mehdi Sheikhalishahi < mehdi.alish...@gmail.com> wrote: > Hi, > > I would like to bring Dynamic VM Consolidation capability into Nova. That > is I would like to check compute nodes status periodically (let's say every > 15 minutes) and consolidate VMs if there is a

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On Nov 18, 2014, at 5:31 PM, Mark McClain wrote: > All- > > Over the last several months, the members of the Networking Program have been > discussing ways to improve the management of our program. When the Quantum > project was initially launched, we envisioned a combined service that > in

Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum wrote: > Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800: > > Greetings, > > > > Regardless of how big/small bugs backlog is for each project, I > > believe this is a common, annoying and difficult problem. At the oslo > > meeting

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

On Tue, Nov 18, 2014 at 07:33:54AM -0500, Sean Dague wrote: > Or just abandon and let people restore. I think handling the logic / > policy for the edge cases isn't worth it when the author can very easily > hit the restore button to get their patch back (and fresh for another 4w). As a non-core d

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

On Tue, Nov 18, 2014 at 6:17 AM, Daniel P. Berrange wrote: > On Tue, Nov 18, 2014 at 07:33:54AM -0500, Sean Dague wrote: > > On 11/18/2014 07:29 AM, Daniel P. Berrange wrote: > > > On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: > > >> Nova currently has 197 patches that have seen no

[openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

All- Over the last several months, the members of the Networking Program have been discussing ways to improve the management of our program. When the Quantum project was initially launched, we envisioned a combined service that included all things network related. This vision served us well i

Re: [openstack-dev] [nova] policy on old / virtually abandoned patches

On Tue, Nov 18, 2014 at 11:44 PM, Jay Pipes wrote: > On 11/18/2014 07:29 AM, Daniel P. Berrange wrote: > >> On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: >> >>> Nova currently has 197 patches that have seen no activity in the last 4 >>> weeks (project:openstack/nova age:4weeks statu

Re: [openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?

On 11/18/2014 3:57 PM, Matt Riedemann wrote: On 11/18/2014 3:28 PM, Vishvananda Ishaya wrote: AFAIK they are relics. Vish On Nov 13, 2014, at 7:20 AM, Matthew Booth wrote: There are 3 db apis relating to ProviderFirewallRule: provider_fw_rule_create, provider_fw_rule_get_all, and provid

[openstack-dev] [neutron] SPD/SAD for Neutron

Per discussion in the meeting today, there were questions on when the Spec Proposal Deadline (SPD) and Spec Approval Deadline (SAD) were for Neutron. I've put these on the Kilo Release Plan wiki page [1], and wanted to let the community know the dates here as well: SPD: Monday 12-8-2014 SAD: Monda

Re: [openstack-dev] [Horizon] proposal: alternating weekly meeting time [doodle poll created]

Thanks everyone who has responded. I'm going to leave the poll open until the weekend to allow for stragglers to get their times in, and then close it and we can see what the results are. The poll is at https://doodle.com/47h3f35nad62ncnf scroll to the far right to set your timezone. Richar

[openstack-dev] [neutron] neutron-drivers meeting moved by 30 minutes

Due to a scheduling conflict, I moved the meeting. It's now from 1530-1630 UTC on Wednesdays [1]. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.ope

Re: [openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?

On 11/18/2014 3:28 PM, Vishvananda Ishaya wrote: AFAIK they are relics. Vish On Nov 13, 2014, at 7:20 AM, Matthew Booth wrote: There are 3 db apis relating to ProviderFirewallRule: provider_fw_rule_create, provider_fw_rule_get_all, and provider_fw_rule_destroy. Of these, only provider_fw_r

Re: [openstack-dev] [Ironic] Proposing new meeting times

On Tue, Nov 18, 2014 at 8:26 PM, Lucas Alvares Gomes wrote: > On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen > wrote: > > > > Option #1: alternate between Monday 1900 UTC && Tuesday 0900 UTC. I like > > this because 1900 UTC spans all of US and western EU, while 0900 > combines EU > >

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

Salvatore Orlando wrote on 11/18/2014 04:15:35 PM: > From: Salvatore Orlando > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 11/18/2014 04:19 PM > Subject: Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping > an L2 agent debt repayment task force > > I

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

Hi Carl, Thanks for kicking this off. I am also willing to help as a core reviewer of blueprints and code submissions only. As for the ML2 agent, we all know that for historic reasons Neutron has grown to be not only a networking orchestration project but also a reference implementation that is r

Re: [openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning

Excerpts from Gregory Haynes's message of 2014-10-09 20:32:26 +: > Hello TripleO-ers, > > Last time around there was a lot of feedback that we should plan our > mid-cycle metup a lot sooner, so lets do that! I've created a (mostly > bare) etherpad here: > > https://etherpad.openstack.org/p/ki

Re: [openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?

AFAIK they are relics. Vish On Nov 13, 2014, at 7:20 AM, Matthew Booth wrote: > There are 3 db apis relating to ProviderFirewallRule: > provider_fw_rule_create, provider_fw_rule_get_all, and > provider_fw_rule_destroy. Of these, only provider_fw_rule_get_all seems > to be used. i.e. It seems th

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

I think we should also get rid of some nonsenses in the way events are processed by the l2 agent. Carl did something similar for the l3 agent. In the past release cycle I put some patches to avoid event starvation or to prevent the same event to be processed multiple times, but I did not address th

Re: [openstack-dev] [OpenStack-dev][Nova] Migration stuck - resize/migrating

Migrate/resize uses scp to copy files back and forth with the libvirt driver. This shouldn’t be necessary with shared storage, but it may still need ssh configured between the user that nova is running as in order to complete the migration. It is also possible that there is a bug in the code pat

Re: [openstack-dev] [barbican] Secret store API validation

> It seems we need to add some validation to the process Yes, we are planning to add some validation checks in Kilo. I would submit a bug report for this. The big part of the issue is that we need to be clearer about the expected input types to the API as well as the SecretStores. This was a big

Re: [openstack-dev] [Solum] Contributing to Solum

Hi Devdatta, > Hi Keyvan, > > Great to hear that your team is interested in contributing to Solum. > > While there is no 'Ideas' page, there is this: > https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap Hmmm, surely this is a good breakdown of the milestones, but not understandable from a n

[openstack-dev] [Keystone] Mid-Cycle Meetup Dates/Time/Location

I am happy to announce a bunch of the information for the Keystone mid-cycle meetup. The selection of dates, location, etc is based upon the great feedback I received from the earlier poll. Currently the only thing left up in the air is the specific venue and recommended hotel(s). Location: San

Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning

I'm very much interested in this new Keystyone thing. Is the name still open to debeate? On Wed, Nov 12, 2014 at 9:26 AM, Brad Topol wrote: > I have filled out the form and very much look forward to attending!!! > > > Brad Topol, Ph.D. > IBM Distinguished Engineer > OpenStack > (919) 543-0646 >

Re: [openstack-dev] oslo.db 1.1.0 released

On Nov 18, 2014, at 12:26 PM, Mike Bayer wrote: > >> On Nov 18, 2014, at 11:47 AM, Sean Dague wrote: >> >> >> Also can I request that when deprecating methods in oslo libraries we >> use a standard deprecation mechanism so that warnings are emitted when >> this method is used. > > +1 for De

Re: [openstack-dev] [Ironic] A mascot for Ironic

On 11/16/2014 10:51 AM, David Shrewsbury wrote: > >> On Nov 16, 2014, at 8:57 AM, Chris K > > wrote: >> >> How cute. >> >> maybe we could call him bear-thoven. >> >> Chris >> > > I like Blaze Bearly, lead singer for Ironic Maiden. :) > > https://en.wikipedia.org/wi

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 19 November 2014 03:14, Radomir Dopieralski wrote: > On 18/11/14 12:54, Matthias Runge wrote: > > On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote: > >> I guess I got the message that turning bower packages into system > packages > >> was something that the Linux packagers were no

Re: [openstack-dev] Quota management and enforcement across projects

On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell wrote: > On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote: >> I’ve spent a bit of time thinking about the resource ownership issue. >> The challenge there is we don’t currently have any libraries that >> define tables in the schema of an appl

Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800: > Greetings, > > Regardless of how big/small bugs backlog is for each project, I > believe this is a common, annoying and difficult problem. At the oslo > meeting today, we're talking about how to address our bug triage > process

Re: [openstack-dev] [Keystone] New Policy Administration Service

Based on the thread entitled [all][policy][keystone] Better Policy Model and Representing Capabilites from October 20, I wrote some code to pull a policy.json file into Congress and figure out what roles are necessary to give access to a specific API call. So if bundling this kind of functional

Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs

The discussion about whether flavors should exist as-is or be decomposed is useful and should continue. It is, however, somewhat orthogonal to the discussion I was hoping to have on this thread :) So coming back to the original question (now generalized away from flavors): how should resource r

Re: [openstack-dev] [Glance] Poll for change in weekly meeting time.

We've had a few responses to this poll however, they do not seem to cover the entire set of developers including many of the cores and developers who are going to be actively working on the features this cycle. Based on the responses received, I'd like to propose a (unified - no alternating) ti

[openstack-dev] [Neutron] DB: transaction isolation and related questions

Hi neutron folks, There is an ongoing effort to refactor some neutron DB logic to be compatible with galera/mysql which doesn't support locking (with_lockmode('update')). Some code paths that used locking in the past were rewritten to retry the operation if they detect that an object was modified

Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework to make the agent code more modular, avoid code replication across multiple L2 agents, and to make adding new features and writing new agents (if/when necessary) easier. I

Re: [openstack-dev] [Keystone] Alternative federation mapping

We started an etherpad to gather requirements etc: https://etherpad.openstack.org/p/mapping-engine-enhancements ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][stable] Review request

Neutron cores: I submitted a bug fix a bit over a month ago which is waiting for one more core (+2) review. The changes are rather simple which affects the ovs/ofa code. Could a core person take the time to review? Here are the pointers to the changes: https://review.openstack.org/127654 https

Re: [openstack-dev] [Fuel] NTP settings.

Yes, it does. On Sat, Nov 15, 2014 at 3:15 AM, Rick Jones wrote: > On 11/14/2014 04:01 PM, Dmitry Borodaenko wrote: > >> If NTP server is not reachable on the first boot of the master node, >> it should be disabled by bootstrap_admin_node, that eliminates the >> possibility of it spontaneously c

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

> > I think for this cycle we really do need to focus on consolidating and > testing the existing driver design and fixing up the biggest > deficiency (1) before we consider moving forward with lots of new +1 > 1) Outbound messaging connection re-use - right now every outbound > messaging creat

Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

Flavio Percoco wrote: > On 18/11/14 11:42 +0100, Thierry Carrez wrote: >>> With storyboard.openstack.org looming >>> on the horizon, should such an effort be put on the back burner for now? >> >> I don't expect integrated projects to be able to switch to storyboard

[openstack-dev] [Glance][stable] Review request

Hi All, Greetings!!! Can anyone please review this patch [1]. It requires one more +2 to get merged in stable/juno. We want to use stable/juno in production environment and this patch will fix the blocker bug [1] for restrict download image feature. Please do the needful. [1] https://review.ope

Re: [openstack-dev] [Neutron] Stale patches

On Tue, Nov 18, 2014 at 7:39 AM, Jeremy Stanley wrote: > This has come up before... if you don't want to see stale patches > you can use Gerrit queries or custom dashboards to only show you > patches with recent activity. If all patches older than some > specific date get abandoned, then that impa

Re: [openstack-dev] oslo.db 1.1.0 released

Well, we can re-define is_backend_avail() in Nova code and use it instead of oslo.db's function. it looks a bit ugly but it will be fast > Also can I request that when deprecating methods in oslo libraries we > use a standard deprecation mechanism so that warnings are emitted when > this method is

Re: [openstack-dev] oslo.db 1.1.0 released

> On Nov 18, 2014, at 11:47 AM, Sean Dague wrote: > > > Also can I request that when deprecating methods in oslo libraries we > use a standard deprecation mechanism so that warnings are emitted when > this method is used. +1 for DeprecationWarnings, I noticed oslo.db doesn’t seem to use these

[openstack-dev] [Ironic] Cleaning up spec review queue.

Hi all, In an effort to keep the Ironic specs review queue as up to date as possible, I have identified several specs that were proposed in the Juno cycle and have not been updated to reflect the changes to the current Kilo cycle. I would like to set a deadline to either update them to reflect th

[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work was identified for the L2 agent. We had a discussion in the Neutron meeting today about bootstrapping that work. The first order of business will be to generate a blueprint specification for the wor

[openstack-dev] [all] OpenStack Bootstrapping Hour: Debugging in the Gate - Friday Nov 21st 20:00 UTC (15:00 Americas/New_York)

This Friday's Bootstrapping Hour will be on Debugging in the Gate - https://wiki.openstack.org/wiki/BootstrappingHour/Debugging_Gate#Debugging_in_the_Gate The etherpad has the discussions notes I'll be using for it - https://etherpad.openstack.org/p/obh-debugging-openstack-gate For folks that can

Re: [openstack-dev] [Ironic] Proposing new meeting times

On Tue, Nov 18, 2014 at 01:00:04AM +, Devananda van der Veen wrote: > Hi all, > > As discussed in Paris and at today's IRC meeting [1] we are going to be > alternating the time of the weekly IRC meetings to accommodate our > contributors in EMEA better. No time will be perfect for everyone, bu

Re: [openstack-dev] [Solum] Contributing to Solum

Hi Keyvan, good to know of your interest in contributing to project Solum. If useful, Adrian and myself are available for a call with you to better understand your motivation around Solum and help you with getting plugged in a meaningful way. From: Keyvan Mir Mohammad Sadeghi [mailto:keyvan.m.s

Re: [openstack-dev] Zero MQ remove central broker. Architecture change.

On 18/11/14 16:33 +0800, Li Ma wrote: On 2014/11/17 22:26, Russell Bryant wrote: On 11/17/2014 05:44 AM, Ilya Pekelny wrote: Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. On a related note, have you looked into AMQP

Re: [openstack-dev] oslo.db 1.1.0 released

Is there a more minimal version of https://review.openstack.org/#/c/103920/ that *just* fixes this issue. So we can evaluate the refactor on it's own, but get the bug fixed more immediately. Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism

Re: [openstack-dev] Quota management and enforcement across projects

On 18 November 2014 01:18, Kevin L. Mitchell wrote: > On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote: > > I’ve spent a bit of time thinking about the resource ownership issue. > > The challenge there is we don’t currently have any libraries that > > define tables in the schema of an appli

Re: [openstack-dev] oslo.db 1.1.0 released

Matt, As for race in Nova - it caused by deprecated is_backend_avail() function, which calls _ensure_backenv_available() method, which creates a SQLAlchemy engine and opens a test connection, but doesn't call engine.dispose(). Depending on Python interpreter version, this connection may remain ope

Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon

On 18/11/14 12:54, Matthias Runge wrote: > On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote: >> I guess I got the message that turning bower packages into system packages >> was something that the Linux packagers were not keen on. Did I get the >> message wrong there? If so, *and* we c

[openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

Hello Community, When a network subnet runs out of IP addresses a request to create a VM on that network fails with the Error message: "No valid host was found. There are not enough hosts available." In the nova logs the error message is: NoMoreFixedIps: No fixed IP addresses available for ne

Re: [openstack-dev] oslo.db 1.1.0 released

On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global

Re: [openstack-dev] [Ironic] Proposing new meeting times

I would vote +1 for option #2, While I may not make many of the 0500 meetings, I could. So I see this as the best option. Chris On Tue, Nov 18, 2014 at 2:11 AM, Zhongyue Luo wrote: > +1 for Option #2 > > On Tue, Nov 18, 2014 at 5:56 PM, Lucas Alvares Gomes < > lucasago...@gmail.com> wrote: > >>

[openstack-dev] Dynamic VM Consolidation Agent as part of Nova

Hi, I would like to bring Dynamic VM Consolidation capability into Nova. That is I would like to check compute nodes status periodically (let's say every 15 minutes) and consolidate VMs if there is any opportunity to turn off some compute nodes. Any hints on how to get into this development proce

Re: [openstack-dev] [Neutron] Stale patches

> -Original Message- > From: Jeremy Stanley [mailto:fu...@yuggoth.org] > Sent: 18 November 2014 14:40 > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron] Stale patches > > On 2014-11-18 05:55:55 + (+), Kenichi Oomichi wrote: >

  1   2   >