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-operators] Cloud Upgrade Strategies

Database only needed for control operations. During upgrade we disable API (mark down on LB or take them down). This will prevent users from making any database changes.  After that flow is "simple"- backup db - do a migration- perform your validation tests If all good, bring up your api, if

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-operators] Cloud Upgrade Strategies

On 10 March 2016 at 19:26, Yuriy Brodskiy wrote: > building a new cloud is not practical for real production environments. > even if you can afford it, how do you migrate data? > > We have been doing upgrades for a while now, and came up with few basic > principles: > 1) you

Re: [Openstack-operators] Cloud Upgrade Strategies

building a new cloud is not practical for real production environments. even if you can afford it, how do you migrate data? We have been doing upgrades for a while now, and came up with few basic principles: 1) you don't have to upgrade all at the same time. do it component at the time 2) stand

Re: [Openstack-operators] What are you excited for in Mitaka?

On 10 March 2016 at 16:33, Matt Kassawara wrote: > Don't forget about fixing MTU in neutron. No more confusing options that > don't really do anything. Does this mean we can modify the MTU via the API now? -- Marcus Furlong ___

Re: [Openstack-operators] What are you excited for in Mitaka?

I really like the MTU one! That was a good hit! Edgar From: Matt Kassawara > Date: Wednesday, March 9, 2016 at 9:33 PM To: Matt Jarvis > Cc: OpenStack Operators

[Openstack] Metadata server issues [Icehouse].

So, I've got an Icehouse cloud that had been working fine; then we had to bring everything down for an extended power outage, and stuff still isn't quite right. The nutshell problem is that only one of my two neutron gateways seems to be able to route to the metadata server. The "working"

Re: [Openstack-operators] What are you excited for in Mitaka?

Don't forget about fixing MTU in neutron. No more confusing options that don't really do anything. On Tue, Mar 8, 2016 at 12:12 PM, Matt Jarvis wrote: > We've just patched in https://review.openstack.org/#/c/262740/ on Kilo. > > On 8 March 2016 at 17:33, Jesse

Re: [Openstack] swift ringbuilder and disk size/capacity relationship

On 10/03/16 00:03, Peter Brouwer wrote: Indeed, I should have been a bit more clear with my question. What is swifts behavior of a situation in which a disk where a swift partition points to runs out of space? There can be a number of swift partitions that point to the same disk, does each

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

[Openstack] [OSSA 2016-007.1] Nova host data leak through resize/migration (CVE-2016-2140) ERRATA

= OSSA-2016-007.1: Nova host data leak through resize/migration = :Date: March 08, 2016 :CVE: CVE-2016-2140 Affects ~~~ - Nova: <=2015.1.3, >=12.0.0 <=12.0.2 Description

[openstack-announce] [OSSA 2016-007.1] Nova host data leak through resize/migration (CVE-2016-2140) ERRATA

= OSSA-2016-007.1: Nova host data leak through resize/migration = :Date: March 08, 2016 :CVE: CVE-2016-2140 Affects ~~~ - Nova: <=2015.1.3, >=12.0.0 <=12.0.2 Description

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

[OpenStack-Infra] JJB nested template variables

Hi Everyone, I'm trying to nest template variables and discovered that JJB behaves in a way I didn't expect when a template variable is nested. For example: - project: name: test jobs: - '{name}-verify-{value}-{jdk}' value: - a: jdk: -

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-operators] [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

[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

[OpenStack-Infra] Request to add project to openstack/ namespace

Greetings, infra team I would like to ask for review of the following change: https://review.openstack.org/#/c/286137/ It adds project called 'fuel-tuning-box'. This is the Fuel Configuration Store service, a component of Fuel architecture facilitating the flow of the configuration data between

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-operators] [openstack-operators][neutron] use-case for multiple routers within a tenant

That makes perfect sense. Thank you. On Wed, Mar 9, 2016 at 4:28 AM, Fox, Kevin M wrote: > We use them all the time, and openstack in one version actually broke them > on us. (I wrote and contributed a unit test so it shouldn't happen again.) > > Use case: > > You have two

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] dhcp to external device from openstack-dhcp on a vlan tenant network

Hi George - Thanks for that - I can see that the host file specified in the --dhcp-hostsfile argument fed to dnsmasq (/var/lib/neutron/dhcp/UUID/host) gets populated by openstack as follows: --- fa:16:3e:58:17:53,host-10-20-50-202.openstacklocal.,10.20.50.202

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] Fine-grained control of designate domain policy

On 03/09/2016 10:17 AM, Andrew Bogott wrote: Thanks for the quick response, Adam! Responses inline... On 3/9/16 8:16 AM, Adam Young wrote: On 03/08/2016 10:48 PM, Andrew Bogott wrote: Due to the weird public/private hybrid nature of my cloud, I'm frequently needing to abuse policy.conf files

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

[Openstack] Error: Unable to create new image [Liberty]

Hi, all. In our Icehouse cloud, I had no problems with non-admin users creating images. In the Liberty cloud we recently stood up, however, that doesn't appear to be enabled. From reading, I see that it appears to be a setting that needs to be altered in /etc/glance/glance-api.conf, but

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-operators] Liberty Setup - Can't ping Demo Router

Hi all; Following the Neutron (Network Option 2 setup) instructions in Liberty. I can't ping my demo router. However, I do recall there are new security constraints that might prevent this in Liberty. Do I need to somehow allow ICMP? Here's what I did.

[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

[Openstack] Registration Prices Increase March 11 - OpenStack Summit Austin

Hi everyone, The early bird registration deadline for the Austin Summit is this Thursday, March 10 at 11:59pm PST (March 11 at 7:59 UTC). Prices will increase immediately following that time. Register NOW to hear from OpenStack users

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

  1   2   >