Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 06/10/15 17:52 +0200, Julien Danjou wrote: On Tue, Oct 06 2015, Flavio Percoco wrote: I send patches to Glance from time to time, and they usually got 0 review for *weeks* (sometimes months, because, well there are no reviewers active in Glance, so: 1) Lets do this on patches that haven't h

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 06/10/15 12:11 -0400, Nikhil Komawar wrote: Overall I think this is a good idea and the time frame proposal also looks good. Few suggestions in-line. On 10/6/15 10:36 AM, Flavio Percoco wrote: Greetings, Not so long ago, Erno started a thread[0] in this list to discuss the abandon

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 06/10/15 17:54 +0200, Victor Stinner wrote: Hi, Le 06/10/2015 16:36, Flavio Percoco a écrit : Not so long ago, Erno started a thread[0] in this list to discuss the abandon policies for patches that haven't been updated in Glance. (...) 1) Lets do this on patches that haven't had any activity

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 06/10/15 13:53 -0400, Doug Hellmann wrote: Excerpts from Flavio Percoco's message of 2015-10-06 23:36:53 +0900: Greetings, Not so long ago, Erno started a thread[0] in this list to discuss the abandon policies for patches that haven't been updated in Glance. I'd like to go forward and start

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 06/10/15 23:36 +0900, Flavio Percoco wrote: Greetings, Not so long ago, Erno started a thread[0] in this list to discuss the abandon policies for patches that haven't been updated in Glance. I'd like to go forward and start following that policy with some changes that you can find below: 1)

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On Wed, Oct 07 2015, Flavio Percoco wrote: > I'm not trying to solve the lack of reviews in Liberty by removing > patches. What I'd like to do, though, is help to keep around patches > that really matter. I think that's where you are making a mistake. They are contributors, like me or Victor, are

Re: [openstack-dev] [nova] live migration in Mitaka

On Tue, Oct 06, 2015 at 06:27:12PM +0100, Paul Carlton wrote: > > > On 06/10/15 17:30, Chris Friesen wrote: > >On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: > >>On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: > >>>https://review.openstack.org/#/c/85048/ was raised to address the

Re: [openstack-dev] [nova] live migration in Mitaka

On Tue, Oct 06, 2015 at 11:43:52AM -0600, Chris Friesen wrote: > On 10/06/2015 11:27 AM, Paul Carlton wrote: > > > > > >On 06/10/15 17:30, Chris Friesen wrote: > >>On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: > >>>On Tue, Oct 06, 2015 at 02:54:21PM +0100, Paul Carlton wrote: > https://revi

Re: [openstack-dev] [nova] live migration in Mitaka

I'd be happy to take this on in Mitaka On 07/10/15 10:14, Daniel P. Berrange wrote: On Tue, Oct 06, 2015 at 11:43:52AM -0600, Chris Friesen wrote: On 10/06/2015 11:27 AM, Paul Carlton wrote: On 06/10/15 17:30, Chris Friesen wrote: On 10/06/2015 08:11 AM, Daniel P. Berrange wrote: On Tue, Oc

Re: [openstack-dev] [nova] live migration in Mitaka

On Wed, Oct 07, 2015 at 10:26:05AM +0100, Paul Carlton wrote: > I'd be happy to take this on in Mitaka Ok, first step would be to re-propose the old Kilo spec against Mitaka and we should be able to fast-approve it. > >>>So my reading of this is the issue could be addressed in Mitaka by > >>>impl

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

I can' say that I have any great plans for this cycle, but I would like look into L3 HA (L3 HA + DVR) feature, probably some bugfixes in this area and online data migration as logical continuation of online migration support that was done in Liberty. On Tue, Oct 6, 2015 at 8:34 PM, Ihar Hrachyshka

Re: [openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

Sheena, thanks. I agree with Chris full Multi-DC it's different scale task. For now Services just need +1 tiny step from Fuel/Product in favor supporting current Multi-DC deployments architectures. (i.e. shared Keystone) Andrew, Ruslan, Mike, i've created tiny blueprint https://blueprints.launch

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 07/10/15 11:12 +0200, Julien Danjou wrote: On Wed, Oct 07 2015, Flavio Percoco wrote: I'm not trying to solve the lack of reviews in Liberty by removing patches. What I'd like to do, though, is help to keep around patches that really matter. I think that's where you are making a mistake. T

Re: [openstack-dev] [puppet] Running Debian packages on top of Trusty

Hi, On 2 Oct 2015, iberezovs...@mirantis.com wrote: > Hello, > > thanks for bringing up this topic, that's what I wanted to discuss on > next puppet-openstack irc meeting. > > So, user case is following: users may want to install Debian packages > on Ubuntu host or vice versa, > the same problem

Re: [openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

Hi, although I'm not participating in this story since very beginning, let me add my 2 cents. For scalability purposes Nova considers rather use of 'cells' rather than 'regions' construct. Regions as name suggests deals with geographically dispersed data centre locations. In regards to Fuel archite

[openstack-dev] [nova] revisiting minimum libvirt version

The following review https://review.openstack.org/#/c/171098 attempts to raise the minimum libvirt version to 1.0.3. In May that was considered a no go - http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.html Can we reconsider that decision and up this to 1.2 for what we're

Re: [openstack-dev] [nova][neutron] ports management

Just some initial thoughts here, as I'm not yet clear on many of your details. On 06/10/15 16:55, Peter V. Saveliev wrote: > … > > > The problem. > > > > There are use cases, when it us needed to attach vnic to some specific > network interface instead of br-int. > > For example, wor

[openstack-dev] [Glance] Glance review dashboard

Greetings, I brought this up at our meeting last week and I'd like to reach a broader audience. I've put together a dashboard[0] for Glance reviews to help increasing focus on relevant patches. This dashboard is generated using gerrit-dash-creator[1] and contributions/feedback are more than welc

[openstack-dev] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and printed a warning on startup if you had < 0.10.2, to the effect that Mitaka will required 0.10.2 This mail is a reminder that we will[1] mandate libvirt >= 0.10.2 when Mitaka is released. Looking forward to the N release,

Re: [openstack-dev] [nova] revisiting minimum libvirt version

On Wed, Oct 07, 2015 at 06:32:53AM -0400, Sean Dague wrote: > The following review https://review.openstack.org/#/c/171098 attempts to > raise the minimum libvirt version to 1.0.3. > > In May that was considered a no go - > http://lists.openstack.org/pipermail/openstack-operators/2015-May/007012.h

Re: [openstack-dev] [Manila] CephFS native driver

On Tue, Oct 6, 2015 at 11:59 AM, Deepak Shetty wrote: >> >> Currently, as you say, a share is accessible to anyone who knows the >> auth key (created a the time the share is created). >> >> For adding the allow/deny path, I'd simply create and remove new ceph >> keys for each entity being allowed/

Re: [openstack-dev] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On Wed, Oct 07, 2015 at 11:46:58AM +0100, Daniel P. Berrange wrote: > In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and > printed a warning on startup if you had < 0.10.2, to the effect that > Mitaka will required 0.10.2 > > This mail is a reminder that we will[1] mandate libv

Re: [openstack-dev] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On 10/07/2015 06:46 AM, Daniel P. Berrange wrote: > In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and > printed a warning on startup if you had < 0.10.2, to the effect that > Mitaka will required 0.10.2 > > This mail is a reminder that we will[1] mandate libvirt >= 0.10.2 when

Re: [openstack-dev] [nova] revisiting minimum libvirt version

On 10/07/2015 06:51 AM, Daniel P. Berrange wrote: > On Wed, Oct 07, 2015 at 06:32:53AM -0400, Sean Dague wrote: >> The following review https://review.openstack.org/#/c/171098 attempts to >> raise the minimum libvirt version to 1.0.3. >> >> In May that was considered a no go - >> http://lists.opens

Re: [openstack-dev] [Fuel] py.test vs testrepository

What I can extract now from this thread is that Fuel should switch to testr because of the following reasons: - Diversity of tools is a bad idea on a project scale - testrepository and related components are used in OpenStack Infra environment for much more tasks than just running tests - py.tes

Re: [openstack-dev] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On Wed, Oct 07, 2015 at 06:55:44AM -0400, Sean Dague wrote: > On 10/07/2015 06:46 AM, Daniel P. Berrange wrote: > > In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and > > printed a warning on startup if you had < 0.10.2, to the effect that > > Mitaka will required 0.10.2 > > >

[openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

Before we had devstack plugins, we had a kind of janky extras.d mechanism. A bunch of projects implemented some odd copy / paste mechanism in test jobs to use that in unexpected / unsupported ways. We've had devstack plugins for about 10 months. They provide a very "pro user" experience by letting

Re: [openstack-dev] [all] -1 due to line length violation in commit messages

On Fri, Sep 25, 2015 at 3:44 PM, Ihar Hrachyshka wrote: > Hi all, > > releases are approaching, so it’s the right time to start some bike > shedding on the mailing list. > > Recently I got pointed out several times [1][2] that I violate our commit > message requirement [3] for the message lines t

Re: [openstack-dev] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: 07 October 2015 13:02 > To: Sean Dague > Cc: OpenStack Development Mailing List (not for usage questions) > ; openstack- > operat...@lists.openstack.org > Subject: Re: [Openstack-operators] [openstack-dev]

Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

On 07/10/15 12:12, Sean Dague wrote: > We've had devstack plugins for about 10 months. They provide a very "pro > user" experience by letting you enable arbitrary plugins with: > > enable_plugin $name git://git.openstack.org/openstack/$project [$branch] > > They have reasonable documentation here >

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko wrote: > What I can extract now from this thread is that Fuel should switch to > testr because of the following reasons: > > - Diversity of tools is a bad idea on a project scale > - testrepository and related components are used in OpenStack I

Re: [openstack-dev] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On 10/07/2015 07:02 AM, Daniel P. Berrange wrote: > On Wed, Oct 07, 2015 at 06:55:44AM -0400, Sean Dague wrote: >> On 10/07/2015 06:46 AM, Daniel P. Berrange wrote: >>> In the Liberty version of OpenStack we had a min libvirt of 0.9.11 and >>> printed a warning on startup if you had < 0.10.2, to th

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 12:51 AM Monty Taylor wrote: > On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote: > > I've already wrote in the review that caused this thread that I do not > want > > to blindly follow rules for using one or another. We should always > consider > > technical requirements.

Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

On 10/07/2015 07:17 AM, Neil Jerram wrote: > On 07/10/15 12:12, Sean Dague wrote: >> We've had devstack plugins for about 10 months. They provide a very "pro >> user" experience by letting you enable arbitrary plugins with: >> >> enable_plugin $name git://git.openstack.org/openstack/$project [$bran

Re: [openstack-dev] [Fuel] py.test vs testrepository

On 10/07/2015 02:06 AM, Monty Taylor wrote: > The Big Tent has absolutely no change in opinion about eliminating > diversity of tools. OpenStack has ALWAYS striven to reduce diversity of > tools. Big Tent applies OpenStack to more things that request to be part > of OpenStack. > > Nothing has chan

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 3:14 AM Monty Taylor wrote: > On 10/06/2015 06:01 PM, Thomas Goirand wrote: > > On 10/06/2015 01:14 PM, Yuriy Taraday wrote: > >> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko >> > wrote: > >> > >> Atm I have the following pros. and cons.

Re: [openstack-dev] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On Wed, Oct 07, 2015 at 11:13:12AM +, Tim Bell wrote: > > Although Red Hat is no longer supporting RHEL 6 after Icehouse, a number of > users such as GoDaddy and CERN are using Software Collections to run the > Python 2.7 code. Do you have any educated guess as to when you might switch to dep

Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

Hi Sean, Do you mean all other projects, like Barbican (non-standard implementation with copy/paste ways) would break in devstack ? Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology

Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

On 07/10/15 12:26, Sean Dague wrote: > On 10/07/2015 07:17 AM, Neil Jerram wrote: >> On 07/10/15 12:12, Sean Dague wrote: >>> We've had devstack plugins for about 10 months. They provide a very "pro >>> user" experience by letting you enable arbitrary plugins with: >>> >>> enable_plugin $name git:/

Re: [openstack-dev] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

On Wed, Oct 07, 2015 at 07:17:09AM -0400, Sean Dague wrote: > On 10/07/2015 07:02 AM, Daniel P. Berrange wrote: > > On Wed, Oct 07, 2015 at 06:55:44AM -0400, Sean Dague wrote: > >> Isn't RHEL 7.1 just an update stream on RHEL 7.0? It seems a little > >> weird to keep the 1.1.1 support instead of ju

Re: [openstack-dev] [Fuel] py.test vs testrepository

Yuri, sticking to global requirements and interacting deeper with OpenStack Infra are up-to-date objectives for Fuel and those are pretty much technical question. However, software development is not only solving technical tasks, it also incorporates interaction between people and other teams s

Re: [openstack-dev] [all] devstack extras.d support going away at M1 - your jobs may break if you rely on it in your dsvm jobs

On 10/07/2015 07:31 AM, Kai Qiang Wu wrote: > Hi Sean, > > > Do you mean all other projects, like Barbican (non-standard > implementation with copy/paste ways) would break in devstack ? Yes, that's what I mean. The copy/paste method will not work after that point, which is why there is a heads u

[openstack-dev] [tc] naming N and O releases nowish

We're starting to make plans for the next cycle. Long term plans are getting made for details that would happen in one or two cycles. As we already have the locations for the N and O summits I think we should do the naming polls now and have names we can use for this planning instead of letters. I

[openstack-dev] [nova] FYI: Updated Mitaka specs template

FYI anyone who is pushing specs for review against Mitaka should be aware that yesterday we merged a change to the spec template. Specifically we have removed the "Project priority" section of the template, since it has been a source of much confusion, cannot be filled out until after the summit de

Re: [openstack-dev] [tc] naming N and O releases nowish

On 07/10/15 07:47 -0400, Sean Dague wrote: We're starting to make plans for the next cycle. Long term plans are getting made for details that would happen in one or two cycles. As we already have the locations for the N and O summits I think we should do the naming polls now and have names we ca

Re: [openstack-dev] [tc] naming N and O releases nowish

On Wed, Oct 07, 2015 at 07:47:31AM -0400, Sean Dague wrote: > We're starting to make plans for the next cycle. Long term plans are > getting made for details that would happen in one or two cycles. > > As we already have the locations for the N and O summits I think we > should do the naming polls

Re: [openstack-dev] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: 07 October 2015 13:25 > To: Tim Bell > Cc: Sean Dague ; OpenStack Development Mailing List > (not for usage questions) ; openstack- > operat...@lists.openstack.org > Subject: Re: [Openstack-operators] [o

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 12:59 PM, Roman Prykhodchenko wrote: > What I can extract now from this thread is that Fuel should switch to testr > because of the following reasons: > > - Diversity of tools is a bad idea on a project scale We already have diversity about frameworks (or lack of them) in O

Re: [openstack-dev] [tc] naming N and O releases nowish

On Oct 7, 2015, at 6:47 AM, Sean Dague wrote: > We're starting to make plans for the next cycle. Long term plans are > getting made for details that would happen in one or two cycles. > > As we already have the locations for the N and O summits I think we > should do the naming polls now and hav

Re: [openstack-dev] [Fuel] py.test vs testrepository

Michał, some comments in-line >> - testrepository and related components are used in OpenStack Infra >> environment for much more tasks than just running tests > > If by "more tasks" you mean parallel testing, py.test also has a > possibility to do that by pytest-xdist. As Monthy mentioned, it’

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

> From: Julien Danjou [jul...@danjou.info] > Sent: 07 October 2015 10:12 > > On Wed, Oct 07 2015, Flavio Percoco wrote: > > > I'm not trying to solve the lack of reviews in Liberty by removing > > patches. What I'd like to do, though, is help to keep around patches > > that really matter. > > I

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

Rich Megginson writes: > On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote: >> Rich Megginson writes: >> >>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote: Gilles Dubreuil writes: > On 30/09/15 03:43, Rich Megginson wrote: >> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote: >>

Re: [openstack-dev] [tc] naming N and O releases nowish

Sean Dague wrote: > We're starting to make plans for the next cycle. Long term plans are > getting made for details that would happen in one or two cycles. > > As we already have the locations for the N and O summits I think we > should do the naming polls now and have names we can use for this >

Re: [openstack-dev] [tc] naming N and O releases nowish

On 10/07/2015 02:57 PM, Thierry Carrez wrote: > ...which if I read it correctly means we could pick N now, but not O. We > might want to change that (again) first. Is this list correct? M = Tokyo N = Atlanta O = Barcelona P = ? Christian. -- Christian Berendt Cloud Solution Architect Mail: ber

Re: [openstack-dev] [puppet] Running Debian packages on top of Trusty

On 10/07/2015 12:22 PM, Sofer Athlan-Guyot wrote: > Hi, > > On 2 Oct 2015, iberezovs...@mirantis.com wrote: > >> Hello, >> >> thanks for bringing up this topic, that's what I wanted to discuss on >> next puppet-openstack irc meeting. >> >> So, user case is following: users may want to install Deb

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

Rich Megginson writes: > On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote: >> Rich Megginson writes: >> >>> On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote: Gilles Dubreuil writes: > On 30/09/15 03:43, Rich Megginson wrote: >> On 09/28/2015 10:18 PM, Gilles Dubreuil wrote: >>

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

On 07/10/15 12:47 +, Bunting, Niall wrote: From: Julien Danjou [jul...@danjou.info] Sent: 07 October 2015 10:12 On Wed, Oct 07 2015, Flavio Percoco wrote: > I'm not trying to solve the lack of reviews in Liberty by removing > patches. What I'd like to do, though, is help to keep around patc

Re: [openstack-dev] [tc] naming N and O releases nowish

On 07/10/15 15:02 +0200, Christian Berendt wrote: On 10/07/2015 02:57 PM, Thierry Carrez wrote: ...which if I read it correctly means we could pick N now, but not O. We might want to change that (again) first. Is this list correct? M = Tokyo N = Atlanta Austin, Texas. O = Barcelona P = ?

Re: [openstack-dev] [tc] naming N and O releases nowish

On 10/07/2015 08:57 AM, Thierry Carrez wrote: > Sean Dague wrote: >> We're starting to make plans for the next cycle. Long term plans are >> getting made for details that would happen in one or two cycles. >> >> As we already have the locations for the N and O summits I think we >> should do the na

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

On Wed, Oct 7, 2015 at 5:44 AM, Anna Kamyshnikova < akamyshnik...@mirantis.com> wrote: > I can' say that I have any great plans for this cycle, but I would like > look into L3 HA (L3 HA + DVR) feature, > The agent side patch was merged yesterday, and the server side patch needs reviews: https://r

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On 10/06/2015 05:15 PM, Thomas Goirand wrote: Hi, tl;dr: let's add a exception handling so that python-*client having conflicting command names isn't a problem anymore, and "openstack help" always work as much as it can. Standardizing on "openstack verb" would likely be the best solution fo

Re: [openstack-dev] [nova] It's time to update the Liberty release notes

Now with committer names. Matt Riedemann said on Thu, Oct 01, 2015 at 01:27:38PM -0500: > Here are the commits in liberty that had the UpgradeImpact tag: % git log --format='%h %<(18,trunc)%cn %s' -i --grep UpgradeImpact \ remotes/origin/stable/kilo..remotes/origin/stable/liberty 0b49934

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On 07/10/15 14:42, Ryan Brown wrote: > On 10/06/2015 05:15 PM, Thomas Goirand wrote: >> Hi, >> >> tl;dr: let's add a exception handling so that python-*client having >> conflicting command names isn't a problem anymore, and "openstack help" >> always work as much as it can. > > Standardizing on "o

Re: [openstack-dev] [Openstack-operators][nova] Nova DB archiving script

On 10/6/2015 11:49 AM, Mike Dorman wrote: I posted a patch against one of the Nova DB archiving scripts in the osops-tools-generic repo a few days ago to support additional tables: https://review.openstack.org/#/c/229013/2 We’d like a few more folks to review to make sure it looks good. Plea

Re: [openstack-dev] [nova] It's time to update the Liberty release notes

This also had DocImpact, but flag was not there. ff80032 Roman Dobosz New nova API call to mark nova-compute down br, Tomi -Original Message- From: EXT Alexis Lee [mailto:lx...@hpe.com] Sent: Wednesday, October 07, 2015 4:42 PM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Glance] Process to clean up the review queue from non-active patches

Excerpts from Flavio Percoco's message of 2015-10-07 16:50:16 +0900: > On 06/10/15 23:36 +0900, Flavio Percoco wrote: > >Greetings, > > > >Not so long ago, Erno started a thread[0] in this list to discuss the > >abandon policies for patches that haven't been updated in Glance. > > > >I'd like to go

Re: [openstack-dev] [tc] naming N and O releases nowish

Is there any reason we can't change that process to align with the longer term planning that's happening around these things? Thanks Carol -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Wednesday, October 07, 2015 5:58 AM To: openstack-dev@lists.openstack.or

Re: [openstack-dev] [Openstack-operators] [nova] Min libvirt for Mitaka is 0.10.2 and suggest Nxxx uses 1.1.1

Please see inline. ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy On 10/7/15, 6:12 AM, "Tim Bell" wrote: > > >> -Original Message- >> From: Daniel P. Berrange [mailto:berra...@redhat.com] >> Sent: 07 October

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On Tue, Oct 6, 2015 at 4:15 PM, Thomas Goirand wrote: > tl;dr: let's add a exception handling so that python-*client having > conflicting command names isn't a problem anymore, and "openstack help" > always work as much as it can. > This creates a first-one-wins scenario that requires *-client i

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown wrote: > Standardizing on "openstack verb" would likely be the > best solution for both the immediate problem and for the broader "naming > stuff" issue. > This is the approach that a number of plugins are taking. I have STRONGLY recommended that the

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

Hello All, Probably quite late answering this email but I want to add our contributions. We will be testing Neutron at scale, so we will be contributing to bugs opened based on the outcome of our tests. We will be also testing concurrency, we are leveraging rally for this goal and also expectin

Re: [openstack-dev] [Neutron] Prepare for expiration bugs without activity

> On 06 Oct 2015, at 19:26, ZZelle wrote: > > Hi everyone, > > > As decided during last neutron meeting[1], we try to let Launchpad expire > outdated bugs. > > The status of every bug without activity in last year has been set to > Incomplete and their assignee/milestone unset in order to le

Re: [openstack-dev] [nova] nova-manage db archive_deleted_rows broken

On 12/12/2014 7:54 PM, melanie witt wrote: Hi everybody, At some point, our db archiving functionality got broken because there was a change to stop ever deleting instance system metadata [1]. For those unfamiliar, the 'nova-manage db archive_deleted_rows' is the thing that moves all soft-d

Re: [openstack-dev] [horizon][keystone]

Hi David,   This sounds like a great set of code, I'm sure we are going to realize we want it sooner or later! Unfortunately I can't consume code in this way (I can't propose code written by somebody else) and I can't spend significant time on it right now.   Would you or Anton be willing to propos

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On 10/07/2015 03:57 PM, Hayes, Graham wrote: > On 07/10/15 14:42, Ryan Brown wrote: >> On 10/06/2015 05:15 PM, Thomas Goirand wrote: >>> P.S: It wasn't the point of this message, but do we have a fix for >>> designateclient? It'd be nice to have this fixed before Liberty is out. > > Is there a bug

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On 10/07/2015 03:39 PM, Ryan Brown wrote: > Sharing a flat namespace is a recipe for pain with a growing number of > projects. Devs and users are unlikely to use every project, they > probably won't notice conflicts naturally except in cases like horizon. Well, users would typically install Horizo

Re: [openstack-dev] [horizon][keystone]

Hi Douglas we are happy for you (or someone else) to submit the code in 3 names: theirs, mine and Anton's. Then this third person can do all the work necessary to get it approved. In this way it is legitimate, since the third person will have contributed to the overall effort. I dont have any spa

Re: [openstack-dev] [horizon][keystone]

Send me what you have, and I will post it as a Work in progress review against Horizon. That way at least it will be available for others to look at and potentially adopt. On 10/07/2015 11:37 AM, David Chadwick wrote: Hi Douglas we are happy for you (or someone else) to submit the code in

Re: [openstack-dev] conflicting names in python-openstackclient: could we have some exception handling please?

On 10/07/2015 10:50 AM, Dean Troyer wrote: > On Wed, Oct 7, 2015 at 8:39 AM, Ryan Brown > wrote: > > Standardizing on "openstack verb" would likely > be the best solution for both the immediate problem and for the > broader "naming stuff" issue. > > > Th

Re: [openstack-dev] [Zaqar][cli][openstackclient] conflict in nova flavor and zaqar flavor

Excerpts from Steve Martinelli's message of 2015-10-06 16:09:32 -0400: > > Using `message flavor` works for me, and having two words is just fine. It might even be good to change "flavor" to "server flavor" (keeping flavor as a backwards-compatible alias, of course). Doug > > I'm in the proces

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

Thanks Ihar. Here is what I plan to work on, or hope to help out with: Continue working on alembic to support online migrations. The alembic migrations seem to be a mysterious thing to many developers. I plan to improve the devref documentation around this. The --autogenerate of revisions, in par

Re: [openstack-dev] [horizon][keystone]

Hi Adam will do (by separate email, so that the list does not receive it) thanks David On 07/10/2015 16:51, Adam Young wrote: > Send me what you have, and I will post it as a Work in progress review > against Horizon. That way at least it will be available for others to > look at and potential

[openstack-dev] Kolla meeting cancelled due to lack of atendees

There were only 3 core reviewers available at the team meeting today and nobody outside the core review team, so cancelled the meeting. I would like folks to make an effort to attend our meeting on October 14th. We will write our final release announcement for Liberty. This process should tak

Re: [openstack-dev] [puppet][keystone] Choose domain names with 'composite namevar' or 'meaningless name'?

On 10/07/2015 09:08 AM, Sofer Athlan-Guyot wrote: Rich Megginson writes: On 10/06/2015 02:36 PM, Sofer Athlan-Guyot wrote: Rich Megginson writes: On 09/30/2015 11:43 AM, Sofer Athlan-Guyot wrote: Gilles Dubreuil writes: On 30/09/15 03:43, Rich Megginson wrote: On 09/28/2015 10:18 PM,

[openstack-dev] [kolla] Meeting cancelled due to lack of atendees

There were only 3 core reviewers available at the team meeting today and nobody outside the core review team, so the 10/7 meeting was cancelled. I would like folks to make an effort to attend our IRC meeting on October 14th. We will write our final release announcement for Liberty. This proces

[openstack-dev] [kolla][release] Announcing Kolla Liberty RC1 available since 9/29

Hey folks, My apologies for not sending out our release announcement for RC1 earlier. I had thought I sent it, but don’t see it on the mailing list archive. The Kolla community is pleased to announce the release of the Kolla Liberty rc1 milestone. This release fixes 87 bugs and implements 10

Re: [openstack-dev] [Manila] CephFS native driver

Hi, John. If you want to discuss this in Tokyo, I suggest you add it to the etherpad: https://etherpad.openstack.org/p/manila-mitaka-summit-topics I look forward to meeting you at the Summit. It¹d be great to see a demo of your Ceph driver. Clinton On 10/7/15, 6:56 AM, "John Spray" wrote:

[openstack-dev] [puppet] WARNING - breaking backwards compatibility in puppet-keystone

tl;dr You must specify a domain when using domain scoped resources. If you are using domains with puppet-keystone, there is a proposed patch that will break backwards compatibility. https://review.openstack.org/#/c/226624/ Replace indirection calls "Indirection calls are replaced with #fetch_

Re: [openstack-dev] [horizon][keystone]

On 10/07/2015 11:51 AM, Adam Young wrote: Send me what you have, and I will post it as a Work in progress review against Horizon. That way at least it will be available for others to look at and potentially adopt. Review has been posted here https://review.openstack.org/232114 I made a best

[openstack-dev] Scheduler proposal

Several months ago I proposed an experiment [0] to see if switching the data model for the Nova scheduler to use Cassandra as the backend would be a significant improvement as opposed to the current design using multiple copies of the same data (compute_node in MySQL DB, HostState in memory in t

[openstack-dev] [Cinder] Google Hangout recording of volume manger locks

Hello folks, I just wanted to post up the YouTube link for the video hangout that the Cinder team just had. We had a good discussion about the local file locks in the volume manager and how it affects the interaction of Nova with Cinder in certain cases. We are trying to iron out how to pr

Re: [openstack-dev] [horizon][keystone]

On 07/10/2015 18:29, Adam Young wrote: > On 10/07/2015 11:51 AM, Adam Young wrote: >> Send me what you have, and I will post it as a Work in progress review >> against Horizon. That way at least it will be available for others to >> look at and potentially adopt. > > Review has been posted here

Re: [openstack-dev] [Neutron] Prepare for expiration bugs without activity

On 7 October 2015 at 07:50, Ihar Hrachyshka wrote: > > On 06 Oct 2015, at 19:26, ZZelle wrote: > > > > Hi everyone, > > > > > > As decided during last neutron meeting[1], we try to let Launchpad > expire outdated bugs. > > > > The status of every bug without activity in last year has been set to

[openstack-dev] [fuel] Last call: Team Structure policy document

All, Looks like we have a consensus on the Team Structure policy [0], unless there are objections in the next 24 hours, I propose to merge it tomorrow. We can always update it with more clarifications and typo fixes later, but for now we need this policy merged to start the Component Leads electio

Re: [openstack-dev] Scheduler proposal

Just a question, Why cassandra? I'm curious what drew u to using that for an experiment? /me not saying its a bad choice, just curious... Ed Leafe wrote: Several months ago I proposed an experiment [0] to see if switching the data model for the Nova scheduler to use Cassandra as the backend

Re: [openstack-dev] [nova] It's time to update the Liberty release notes

- Original Message - > From: "Matt Riedemann" > To: "OpenStack Development Mailing List (not for usage questions)" > > > We need to go through the changes which were tagged for release notes > [1]. Generally this means anything with the UpgradeImpact tag but can > also mean things with

Re: [openstack-dev] Scheduler proposal

On 07/10/15 13:36, Ed Leafe wrote: Several months ago I proposed an experiment [0] to see if switching the data model for the Nova scheduler to use Cassandra as the backend would be a significant improvement as opposed to the current design using multiple copies of the same data (compute_node

[openstack-dev] We should move strutils.mask_password back into oslo-incubator

Here's why: https://review.openstack.org/#/c/220622/ That's marked as fixing an OSSA which means we'll have to backport the fix in nova but it depends on a change to strutils.mask_password in oslo.utils, which required a release and a minimum version bump in global-requirements. To backport

Re: [openstack-dev] [Ironic] backwards compat issue with PXEDeply and AgentDeploy drivers

Ramesh, I thought about your points over night, and then looked at our in-tree driver code from stable/kilo and asked myself, "what if this driver was out of tree?" They'd all have broken -- for very similar reasons as what I encountered with my demo driver. When we split the boot and deploy inte

Re: [openstack-dev] [Neutron][Kuryr] Kuryr Open Tasks

Gal, thx I a lot. I have created the pool http://doodle.com/poll/udpdw77evdpnsaq6 where everyone can vote for time slot. — Egor From: Gal Sagie mailto:gal.sa...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date:

  1   2   >