Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Mike, #1 - If you truly agree with that, you should weigh in here: https://review.openstack.org/#/c/287286/ #2 - Requires a blueprint and new docs, but okay. #3 - Yes! We have very poor CI for fuel plugin builder. All it does is ensure it makes a plugin, not that it can be installed and deployed.

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, Normally I would support your idea, but the reality is any plugin from 7.0 that defines a plugin role isn't going to work in 8.0 or 9.0. We changed too many task names and you just can't make a plugin support both versions not without something incredibly clever that I haven't

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 March 2016 at 18:23, Matthias Runge wrote: > > 4.alt.2: > move to proper packages for static file management. I mean, they need to > be built anyways. > Please define what you mean by "proper packages" here. I *think* you might mean system packages (aka Debian or Red

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Folks, here is what I think: 1) I suggest to fix what is broken now. So that people who come across examples would not have to deal with issues. We may debate for other few days (hopefully not more), and all plugin devs will be suffering during this time. Also, according to Matt, > I should add

[openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi folks, in order to make a decision whether we need to support example plugins, and if actually need them [1], I'd suggest to discuss more common things about plugins. My thoughts: 1) This is not good, that our plugins created for Fuel 8 won't even install on Fuel 9. By default, we should

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On Wed, Mar 09, 2016 at 12:28:59PM -0600, Matt Riedemann wrote: [snipped] > Ha, the irony. > > OK, so I thought awhile back, around YVR summit time, there was a group of > different packagers from different distros (debian/red hat/fedora/suse) that > were working together on some common tooling.

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 09/03/16 19:52, Michael Krotscheck wrote: > On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor > wrote: > > > > SOLUTION 4: vendor the javascript > > > > Heh. > > Heh indeed. > > SOLUTION 4.alt: use npm/bower instead of

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

On 09/03/16 18:26, Doug Hellmann wrote: > It's time to start opening the stable branches for libraries. I've > openstack/django_openstack_auth 2.2.0 Yes please Matthias -- Matthias Runge Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial

Re: [openstack-dev] [nova][cinder] Limits on volume read throughput?

In my case Centos 7 is using QEMU 1.5.3 ... which is *ancient*. This is on a node with a packstack install of OpenStack. If you have a different result, I would like to know why... Got a bit further in my reading and testing. Also got my raw volume read performance in an instance from ~300MB/s

[openstack-dev] [glance]Why vm boots from the cirros image so slow?

hi guys. There is a question confuses me a long time. I create a vm by using the "cirros" image. Why the vm was so slow? In the VNC console, I see these info says "further output written to /dev/tty0". And the vm hangs a long time. What does the vm doing at that time?? Besides, could

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

Flavio, Glance and OpenStack benefited during your reign or period of humble service. Will miss you at the helm. Also thank you for anointing/attracting two new solid cores: Brian and Sabari Malini -Original Message- From: Tom Fifield [mailto:t...@openstack.org] Sent: Wednesday, March

[openstack-dev] Branch miss-match between server and client in Kilo

Hi All Greetings for the day! I have noticed that while installing* OpenStack Kilo* using DevStack, the server components cloned are stable/kilo whereas the client components cloned are master. This leads to errors in installation or commands miss-match. For eg. *In tacker,* tacker git repo is

[openstack-dev] [QA] Meeting Thursday March 10th at 9:00 UTC

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

Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch

A beautiful post, sir. Thank you for everything! On 09/03/16 22:15, Flavio Percoco wrote: Greetings, I'm not going to run for Glance's PTL position for the Newton timeframe. There are many motivations behind this choice. Some of them I'm willing to discuss in private if people are interested

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

On Wed, Mar 09, 2016 at 10:56:04PM +, Andrew Woodward wrote: > Issue: moving to puppet-openstack on master has exposed fuel-library > to breakage and there are many concerns about changes landing that can > break it. > > Alex S. Proposed that we continue the course, and finish setting up >

Re: [openstack-dev] [nova][pci] What is the point of the ALLOCATED vs. CLAIMED device status?

Hi, Jay Here is a rough summary about claimed state: when we resizing VM to same host, suppose we now have PCI A, will renew to B1, B2, before the whole resizing process finished, we given user the change to revert the re-size, it's better reverting to original PCI A, not a new PCI devices.

Re: [openstack-dev] [Horizon] Javascript linting and documentation

On 10 March 2016 at 06:49, Michael Krotscheck wrote: > I guess I don't see what problems is being solved by turning the rule off, > and I also don't see the harm in having more check. It does generate a lot > of warnings, but invoking `npm run lint -- --quiet` gets rid of

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann wrote: > > > The etherpad [1] doesn't discuss any other alternatives that were > evaluated and rejected. Were any other options considered? In > particular, how does this course compare to an event such as the > Community

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

Today we had a sync up call and discussed this. To summarize Attendees: Aleksandr Didenko Alex Schultz Andrew Woodward Alexey Shtokolov Bartek Kupidura Bogdan Dobrelya Denis Egorenko Ivan Berezovskiy Kyrylo Galanov Maksim Malchuk Matthew Mosesohn Max Yatsenko Oleg Gelbukh Oleksiy Molchanov Petr

Re: [openstack-dev] [nova] patches that improve code quality

Ideally it's good practice to do refactoring the codes to add more readability. In reality, it's kind of impossible. Because there might be another process required after refactoring and it would take a time. But that's good point, honestly. On Thu, Mar 10, 2016 at 1:33 AM, Matt Riedemann

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

This is not the first time. Monasca and Murano had a collision too[1]. When this happens the changes trickle down into automation tools also and complicates things. [1] https://bugs.launchpad.net/murano/+bug/1505785 On Wed, Mar 9, 2016 at 3:30 PM, Xav Paice wrote: > From an

Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list

>From an ops point of view, this would be extremely helpful information to share with various teams around an organization. Even a simple wiki page would be great. On 10 March 2016 at 10:35, Fei Long Wang wrote: > Hi all, > > Yesterday I just found cloudkitty is using

[openstack-dev] [Neutron] Linuxbridge gate failures

Neutrinos, We had two back-to-back gate failures on [1,2] and more seem to be ramping up. These are tracked in bug [3] (e-r query tracked in [4]). Can I trouble some gentle soul to have a look? Thanks, Armando [1] https://review.openstack.org/#/c/286818/ [2]

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

2016-03-09 18:26 GMT+01:00 Doug Hellmann : > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed versions from which > we will create stable/mitaka branches, and need each team to sign off on > the versions.

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 3/9/16 4:39 PM, Zane Bitter wrote: On 09/03/16 05:42, Sergey Kraynev wrote: Hi Gary, First of all you don't need to use "depends_on", because using "get_attr" already create implicit dependency from rg_a. About getting Null instead of real Ip address: It sounds like a bug, but IMO, it's

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

On Wed, Mar 09, 2016 at 12:26:18PM -0500, Doug Hellmann wrote: > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed versions from which > we will create stable/mitaka branches, and need each team to sign off on > the versions. If

[openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

+2 for Diana :) - Original message - From: David Lyle To: OpenStack Development Mailing List Cc: Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core Date: Tue, Mar 8, 2016 2:07 PM I propose

Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

On 09/03/16 05:42, Sergey Kraynev wrote: Hi Gary, First of all you don't need to use "depends_on", because using "get_attr" already create implicit dependency from rg_a. About getting Null instead of real Ip address: It sounds like a bug, but IMO, it's expected behavior, because I suppose it

[openstack-dev] [all][zaqar][cloudkitty] Default ports list

Hi all, Yesterday I just found cloudkitty is using the same default port () which is used by Zaqar now. So I'm wondering if there is any rule/policy for those new services need to be aware. I googled but can't find anything about this. The only link I can find is

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

> On 03/09/2016 04:43 PM, Serg Melikyan wrote: >>> >>> This is exactly my first thought. The plugins *must* depend on Horizon, >>> and they have to use the same versions of XStatic packages anyways, > > >> so why specify the dependencies twice? >> >> >> Plugins may require different xstatic

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

On 3/9/2016 2:15 PM, Amrith Kumar wrote: Thanks Matt. Agreed on 1, 2, 3, and 4. The reason for #5 is that there are other changes (for which we have FFE's) which will be merged and a new version of the client requested. Specifically, this change https://review.openstack.org/290177

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

Hi Serg, There's a crucial difference: getting the solution to this wrong for Horizon will break the gate for all OpenStack projects. Updating an xstatic package that a plugin uses has no side-effect outside of the plugin. Richard On 10 March 2016 at 02:43, Serg Melikyan

Re: [openstack-dev] [Horizon] Javascript linting and documentation

Hi Michael, The problem is that the warnings are so great that is really hard to read. What if we amended the recently added lintq to do some inline filtering of the doc warnings? This is just a bandaid of course. I also am opposed to any major linting changes until Mitaka closes. They cause

[openstack-dev] [app-catalog] IRC Meeting Thursday March 10th at 17:00UTC

Join us Thursday for our weekly meeting, scheduled for March 10th at 17:00UTC in #openstack-meeting-3 The agenda can be found here, and please add to if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Looking forward to seeing everyone there

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Hi, Doug Heat team is agree to use python-heatclient == 1.0.0 for creating stable branch On 9 March 2016 at 20:26, Doug Hellmann wrote: > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed versions from

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

Thanks Matt. Agreed on 1, 2, 3, and 4. The reason for #5 is that there are other changes (for which we have FFE's) which will be merged and a new version of the client requested. Specifically, this change https://review.openstack.org/290177 Thanks, -amrith > -Original Message- >

Re: [openstack-dev] [Neutron] Ihar as *-aas core reviewer

I probably speak for all FwaaS cores when I say - "Welcome!" Frankly I had just assumed he had core privileges for our repo anyway via an inherited ACL. -- Sean M. Collins __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

On 3/9/2016 1:34 PM, Amrith Kumar wrote: Matt, We discussed this at the Trove meeting. Here's my current understanding of the situation: 1. Your change https://review.openstack.org/#/c/290048/ which reverts the trove client side of the change should be merged. 2. This change (the Trove

Re: [openstack-dev] [Horizon] Javascript linting and documentation

+1 to what Rob said. I guess I don't see what problems is being solved by turning the rule off, and I also don't see the harm in having more check. It does generate a lot of warnings, but invoking `npm run lint -- --quiet` gets rid of those. Also, from my experience, sphinx-based doc builds are

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Excerpts from Flavio Percoco's message of 2016-03-09 14:55:00 -0400: > On 09/03/16 13:41 -0500, Amrith Kumar wrote: > >Doug, > > > >>> openstack/python-troveclient 2.1.0 > > > >Trove isn't there yet. You are aware of the conversation(s) we're having > >about this, and there are two. > > > >One is

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Flavio, I believe that you are correct and that we don't need a major release. However, just to be positive, and out of an abundance of caution, I'm going to be looking to #openstack-infra or #openstack-release for confirmation. Thanks, -amrith > -Original Message- > From: Flavio

Re: [openstack-dev] [tc] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

Matt, We discussed this at the Trove meeting. Here's my current understanding of the situation: 1. Your change https://review.openstack.org/#/c/290048/ which reverts the trove client side of the change should be merged. 2. This change (the Trove API side)

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On Wed, Mar 9, 2016 at 9:32 AM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500: > > On 03/09/2016 11:36 AM, Doug Hellmann wrote: > > > Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800: > > >> On Tue, Mar 8, 2016

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

+1. Another vote in favor of ditching django altogether is good by me :) On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran wrote: > Big +1 from me, thanks for all the hard work Diana! > > > - Original message - > From: David Lyle > To: OpenStack

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten tohorizon-core

Big +1 from me, thanks for all the hard work Diana!   - Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-coreDate: Tue, Mar 8, 2016

Re: [openstack-dev] [Horizon] Javascript linting and documentation

If possible, I’d really prefer we left linting work to Newton. It’ll be good to get it to a more usable state again, but we ought to be focusing on thoroughly checking the new Launch Instance for bugs and edge usage cases, as well as the outstanding bugs and blueprints targeted at RC1

[openstack-dev] [trove] OpenStack Trove meeting minutes (2016-03-09)

Minutes of the OpenStack Trove meeting held today are at: http://eavesdrop.openstack.org/meetings/trove/2016/trove.2016-03-09-18.00.html -- Amrith Kumar, CTO | amr...@tesora.com Tesora, Inc | @amrithkumar 125 CambridgePark Drive, Suite 400 |

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

On 09/03/16 13:41 -0500, Amrith Kumar wrote: Doug, openstack/python-troveclient 2.1.0 Trove isn't there yet. You are aware of the conversation(s) we're having about this, and there are two. One is the FFE which requires a client change, and the second is the backwards compatibility issue

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On 03/09/2016 10:28 AM, Matt Riedemann wrote: Is that still a thing and if so, do they congregate somewhere? Because *that's* where I think people need to go, not the #openstack-stable channel. There is an #openstack-anvil channel, The anvil project had/has similar goals of being a

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On Wed, Mar 9, 2016 at 7:58 AM Monty Taylor wrote: > > > SOLUTION 4: vendor the javascript > > > > Heh. > > Heh indeed. > > SOLUTION 4.alt: use npm/bower instead of xstatic to pull the javascript. > +1. Let's move the codebase forward, instead of continuing to build hacky

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On 03/09/2016 07:28 PM, Matt Riedemann wrote: > Ha, the irony. > > OK, so I thought awhile back, around YVR summit time, there was a group > of different packagers from different distros (debian/red > hat/fedora/suse) that were working together on some common tooling. > > Is that still a thing

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On 03/09/2016 06:48 PM, Matt Riedemann wrote: > Someone showed up in the -stable channel this morning asking for help > with packaging. I gather they were there because the IRC wiki [1] says > the #openstack-stable channel is also for packaging discussions, given > -stable originated from distro

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Doug, >> openstack/python-troveclient 2.1.0 Trove isn't there yet. You are aware of the conversation(s) we're having about this, and there are two. One is the FFE which requires a client change, and the second is the backwards compatibility issue that Matt raised yesterday. Thanks, -amrith

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Excerpts from Doug Hellmann's message of 2016-03-09 12:26:18 -0500: > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed versions from which > we will create stable/mitaka branches, and need each team to sign off on > the versions.

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On 3/9/2016 11:57 AM, Louis Taylor wrote: On Wed, Mar 9, 2016 at 5:48 PM, Matt Riedemann wrote: Someone showed up in the -stable channel this morning asking for help with packaging. I gather they were there because the IRC wiki [1] says the #openstack-stable

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" wrote: > > On 03/09/2016 04:43 PM, Serg Melikyan wrote: >>> >>> This is exactly my first thought. The plugins *must* depend on Horizon, >>> and they have to use the same versions of XStatic packages anyways, > > >> so why

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

All systems are go for: openstack/keystoneauth 2.3.0 openstack/keystonemiddleware 4.3.0 openstack/pycadf 2.1.0 openstack/python-keystoneclient 2.3.1 From: Doug Hellmann To: openstack-dev Date: 2016/03/09 06:28 PM Subject:

[openstack-dev] [Neutron] stable/mitaka branch imminent for the client

Folks, Please see [1]. I gave Doug the go-ahead. Cheers, Armando [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088853.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Good to go with: openstack/python-neutronclient 4.1.1 Thanks, Armando On 9 March 2016 at 09:26, Doug Hellmann wrote: > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed versions from which > we will

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

On Wed, Mar 9, 2016 at 5:48 PM, Matt Riedemann wrote: > Someone showed up in the -stable channel this morning asking for help with > packaging. I gather they were there because the IRC wiki [1] says the > #openstack-stable channel is also for packaging discussions,

Re: [openstack-dev] The #openstack-packaging channel requires an invite?

It got renamed a couple of months/year ago to #openstack-stable: https://bugs.launchpad.net/openstack-ci/+bug/1360324 Documentation should have been updated to reflect this change. Channel being invite-only is probably a side-effect of the migration. Mathieu On 2016-03-09 12:48 PM, Matt

[openstack-dev] The #openstack-packaging channel requires an invite?

Someone showed up in the -stable channel this morning asking for help with packaging. I gather they were there because the IRC wiki [1] says the #openstack-stable channel is also for packaging discussions, given -stable originated from distro people. I redirected them to

Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

On 02/29/2016 11:19 AM, Vladimir Kuklin wrote: > Hi Ivan > > Thanks for bringing this up. Frankly, I think that we hurried a little > bit by making our integration with upstream puppet manifests too > continuous. I would suppose that we used a little bit different technique. > > First of all, we

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

On 09/03/16 12:26 -0500, Doug Hellmann wrote: It's time to start opening the stable branches for libraries. I've prepared a list of repositories and the proposed versions from which we will create stable/mitaka branches, and need each team to sign off on the versions. If you know you intend to

Re: [openstack-dev] [trove][stable] proboscis tests randomly failing in stable branches; bug 1538506

On 3/9/2016 8:54 AM, Amrith Kumar wrote: Matt, As I understand it, you have 4 changes up for review. Change [1] seeks to revert the change [6] to python-troveclient on master and reinstate the slave_of parameter. Change [2] is doing for stable/liberty, the same things that

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On 03/09/2016 12:32 PM, Doug Hellmann wrote: > Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500: >> On 03/09/2016 11:36 AM, Doug Hellmann wrote: >>> Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800: On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann

Re: [openstack-dev] [nova] bug reports and stable branches: tags or series?

Matt Riedemann wrote on 03/04/2016 04:29:53 PM: > From: Matt Riedemann > To: openstack-dev@lists.openstack.org > Date: 03/04/2016 04:30 PM > Subject: Re: [openstack-dev] [nova] bug reports and stable branches: > tags or series? > > >

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

Hi, from Sahara team side, we're okay with python-saharaclient 0.13.0, no fixes expected. Thanks. On Wed, Mar 9, 2016 at 9:26 AM, Doug Hellmann wrote: > It's time to start opening the stable branches for libraries. I've > prepared a list of repositories and the proposed

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

Excerpts from Sean Dague's message of 2016-03-09 12:22:08 -0500: > On 03/09/2016 11:36 AM, Doug Hellmann wrote: > > Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800: > >> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann > >> wrote: > >> > >>> > >>> > >>>

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

I’m not a core but I wanted to add my complete agreement with making Diana a core in horizon. She has done some incredible work in horizon through her work on the code, reviews and also community attitude and assistance getting people (myself included) familiar with horizon. Beth > On 8 Mar

[openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

It's time to start opening the stable branches for libraries. I've prepared a list of repositories and the proposed versions from which we will create stable/mitaka branches, and need each team to sign off on the versions. If you know you intend to release a bug fix version in the next couple of

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

On 03/09/2016 11:36 AM, Doug Hellmann wrote: > Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800: >> On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann wrote: >> >>> >>> >>> As I understood it when this course was originally proposed, the >>> idea was to

Re: [openstack-dev] [neutron][oslo]neutron agent not receiving callback

Thanks, Yeah I just gone over doc. and tried to use the subscription. After looking into code I understood thats its not for interprocess. @Armando - Thanks for updating faq On Wed, Mar 9, 2016 at 10:40 PM, Armando M. wrote: > > > On 9 March 2016 at 09:14, Assaf Muller

Re: [openstack-dev] [neutron][oslo]neutron agent not receiving callback

On 9 March 2016 at 09:14, Assaf Muller wrote: > On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka > wrote: > > Vikash Kumar wrote: > > > >> > >> > >> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar > >>

[openstack-dev] [Neutron] Ihar as *-aas core reviewer

Folks, I would like to have Ihar as core reviewer for the advanced services (or any neutron-governance project for the time we have those projects in the governance). Ihar is instrumental in ensuring that gate/stable issues are dealt with promptly and swiftly and I trust he'll be using such as

Re: [openstack-dev] [neutron] Last chance to finish changes affecting DB schema for Mitaka

On 9 March 2016 at 07:42, Ihar Hrachyshka wrote: > Henry Gessau wrote: > > By tomorrow we intend to tag the heads of all the neutron alembic branches >> with the MITAKA label [1][2][3][4]. >> >> If you have a patch that adds an alembic migration and you

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

+1 from me. Diana’s almost single handedly fixed our Bootstrap usage and gives lots of great reviews all across Horizon too. The boost to branding, theming and potential for accessibility, as well as huge reduction in CSS/HTML maintenance overhead, has been brilliant. Rob On 9 Mar 2016, at

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

Excerpts from Colette Alexander's message of 2016-03-08 14:34:19 -0800: > On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann wrote: > > > > > > > As I understood it when this course was originally proposed, the > > idea was to have a few folks already in leadership positions go

Re: [openstack-dev] [nova] patches that improve code quality

On 3/9/2016 6:22 AM, Radomir Dopieralski wrote: Some of the code we have in Nova is admittedly hard to read and brittle. This is true even though we cave excellent code review, and the reviewers that deeply care for the quality of code that is being merged. Some of this code has been there

[openstack-dev] [TripleO] Including Aodh and Gnocchi in Mitaka

Hey Guys: As many of you know, we have been working on getting Aodh and Gnocchi support into TripleO. We would like to formally request these two be made blockers to get into Mitaka release for TripleO. We tried to get these into Liberty, but due to time constraints it seems slim that that would

Re: [openstack-dev] [kolla] ubuntu deploy gate

On 2016-03-09 15:32:58 + (+), Vikram Hosakote (vhosakot) wrote: > FYI, the bug is seen in Ubuntu gate just on devstack-trusty-rax > machine and not on devstack-trusty-osic and > devstack-trusty-ovh. Due to long-standing issues uploading images to Rackspace's Glance implementation (and

Re: [openstack-dev] [horizon] Proposal to add Diana Whitten to horizon-core

+1, Diana's contribution to the front-end aspect of Horizon during several recent release cycles was second to none! On Wed, Mar 9, 2016 at 2:15 AM Richard Jones wrote: > +1 we need Diana's perspective, knowledge and enthusiasm > > On 9 March 2016 at 10:03, Tripp, Travis

[openstack-dev] [nfv][telco] Telco Working Group meeting for Wednesday Marcch 16th CANCELLED

Hi all, There will be no Telco Working Group [1] meeting for Wednesday March 16th as we will be lacking a chair. Thanks, Steve [1] https://wiki.openstack.org/wiki/TelcoWorkingGroup __ OpenStack Development Mailing List

Re: [openstack-dev] [neutron][oslo]neutron agent not receiving callback

On Wed, Mar 9, 2016 at 9:40 AM, Ihar Hrachyshka wrote: > Vikash Kumar wrote: > >> >> >> On Wed, Mar 9, 2016 at 3:42 PM, Vikash Kumar >> wrote: >> I have written a sample neutron agent which subscribe for the

Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

Colette Alexander wrote: On Tue, Mar 8, 2016 at 1:37 PM, Doug Hellmann > wrote: As I understood it when this course was originally proposed, the idea was to have a few folks already in leadership positions go take the training

Re: [openstack-dev] [L2-Gateway] Install and Configuration issue

Hi Irena, I was not clear in my initial message...but I am using the stable/liberty branch. It is interesting that the master branch has this set in the plugin now. Clearly the code is evolving a bit for Mitaka. However you helped me to discover what was wrong (I think). I forgot to change to the

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/09/2016 04:43 PM, Serg Melikyan wrote: This is exactly my first thought. The plugins *must* depend on Horizon, and they have to use the same versions of XStatic packages anyways, >> so why specify the dependencies twice? Plugins may require different xstatic library, which is not even

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Because it doesn't make much sense for a plugin developer to have scripts to build packages for installation on slave nodes. For default template it's better to have something minimalistic and the rest of the tasks commented, otherwise it may create a lot of confusion. On Wed, Mar 9, 2016 at 6:37

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

On 03/07/2016 10:52 PM, Richard Jones wrote: We've solved *most* of the issues around releasing new xstatic packages, documented here[1] (and related documentation). We have one final issue that's blocking us, which is that during the xstatic release there will be a point at which Horizon may

[openstack-dev] [all][infra] Switching images for testing

We're migrating already since Friday jobs using the so-called bare-trusty images to ubuntu-trusty images. These images are used for for most of unit and functional tests, for documentation etc. Devstack is still run on devstack-trusty nodes for now, but will also move at a later date. A direct

Re: [openstack-dev] [Horizon] How do we move forward with xstatic releases?

>This is exactly my first thought. The plugins *must* depend on Horizon, and >they have to use the same versions of XStatic packages anyways, so why specify >the dependencies twice? Plugins may require different xstatic library, which is not even used by Horizon. Issue raised by Richard exists

Re: [openstack-dev] [kolla] ubuntu deploy gate

FYI, the bug is seen in Ubuntu gate just on devstack-trusty-rax machine and not on devstack-trusty-osic and devstack-trusty-ovh. Regards, Vikram Hosakote IRC: vhosakot From: "Steven Dake (stdake)" > Reply-To:

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Talking about templates I mean plugins generated by FBP from the `templates` folder using command you mentioned above. Why not to extend (not replace) template-generated plugins with additional data to provide right coverage? On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L wrote:

Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?

On Wed, Mar 9, 2016 at 4:16 PM, Doug Hellmann wrote: > Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > > On 8 March 2016 at 15:07, Doug Hellmann wrote: > > > > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700: > >

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

r/is almost a copy-paste/is almost a copy-paste from plugins templates On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote: > Igor, i completely agree, actually plugin examples is almost a copy-paste. > > The only thing i see useful in the built plugins example is the

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Ilya, What do you mean by "templates" the plugin which is create by just "fpb --create plugin-name"? It doesn't cover enough, package installation and all range of tasks executions. Thanks, On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote: > Igor, i completely agree,

Re: [openstack-dev] [all][release] Release countdown for week R-4, Mar 7 - 11

Excerpts from Sergey Kraynev's message of 2016-03-09 11:08:32 +0300: > Hi Doug. > > I have one question related with last item: "Release actions". > Who will prepare patches for Reno and for updating .gitreview? > Should it be done by related project team or it will be done by someone else? The

Re: [openstack-dev] [neutron][release] Releasing python-neutronclient 4.1.2?

Excerpts from Armando M.'s message of 2016-03-08 15:43:05 -0700: > On 8 March 2016 at 15:07, Doug Hellmann wrote: > > > Excerpts from Armando M.'s message of 2016-03-08 12:49:16 -0700: > > > Hi folks, > > > > > > There's a feature or two that are pending to be delivered in

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Igor, i completely agree, actually plugin examples is almost a copy-paste. The only thing i see useful in the built plugins example is the ability to point some code lines, discussing plugin design and writing documentation. Why not to generate this examples automatically from templates? Also,

Re: [openstack-dev] [app-catalog] Nominating Kirill Zaitsev to App Catalog Core

Thanks everyone, this is an honor and great responsibility. I would do my best as App Catalog Core.  --  Kirill Zaitsev Software Engineer Mirantis, Inc On 9 March 2016 at 05:50:53, Christopher Aedo (d...@aedo.net) wrote: On Thu, Mar 3, 2016 at 1:10 PM, Christopher Aedo wrote:

  1   2   >