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

On Wed, Oct 7, 2015 at 9:40 PM, Egor Guz wrote: > Gal, thx I a lot. I have created the pool > http://doodle.com/poll/udpdw77evdpnsaq6 where everyone can vote for time > slot. > Thanks Egor > > — > Egor > > > From: Gal Sagie

Re: [openstack-dev] Scheduler proposal

Excerpts from Zane Bitter's message of 2015-10-07 12:28:36 -0700: > 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

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

On 10/07/2015 09:24 AM, Sean Dague wrote: 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

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

On Wed, Oct 07, 2015 at 03:02:47PM +0200, Christian Berendt wrote: > Is this list correct? > > M = Tokyo > N = Atlanta > O = Barcelona > P = ? IIRC N should be Austin instead of Atlanta. -- Matthias Runge

Re: [openstack-dev] [Fuel] Core Reviewers groups restructure

While we're waiting for openstack-infra team to finish the stackforge migration and review our ACL changes, I implemented the rest of the changes agreed in this thread: - Fuel-core group removed everywhere. - Per-project core groups populated with individual reviewers as quoted below.

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

Isn't #2 the right approach? Even if it might be more 'work' I personally would prefer #2 and do it right (and make it easier to do the right thing in the future via scripts, automation, other) vs. the other mentioned approaches. If we were consuming, say a 3rd party library and that 3rd

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

On 10/07/2015 06:22 PM, Monty Taylor wrote: > On 10/07/2015 09:24 AM, Sean Dague wrote: >> 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

[openstack-dev] [nova] Intel PCI CI appears lost in the weeds

Was seeing immediate posts on changes which I knew was bogus, and getting 404s on the logs: http://52.27.155.124/232252/1 Anyone know what's going on? -- Thanks, Matt Riedemann __ OpenStack Development Mailing List

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

On 10/07/2015 03:54 PM, Matt Fischer wrote: I thought the agreement was that default would be assumed so that we didn't break backwards compatibility? puppet-heat had already started using domains, and had already written their code based on the implementation where an unqualified name

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

On 8 October 2015 at 08:38, Matt Riedemann wrote: > 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, >

Re: [openstack-dev] Scheduler proposal

On 10/07/2015 11:36 AM, Ed Leafe wrote: I've finally gotten around to finishing writing up that proposal [1], and I'd like to hope that it would be the basis for future discussions about addressing some of the underlying issues that exist in OpenStack for historical reasons, and how we might

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

Matt, My vote is for #1, as we should kill oslo-incubator in Mitaka. Thanks, Dims On Wed, Oct 7, 2015 at 3:38 PM, Matt Riedemann wrote: > Here's why: > > https://review.openstack.org/#/c/220622/ > > That's marked as fixing an OSSA which means we'll have to backport

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

I thought the agreement was that default would be assumed so that we didn't break backwards compatibility? On Oct 7, 2015 10:35 AM, "Rich Megginson" wrote: > tl;dr You must specify a domain when using domain scoped resources. > > If you are using domains with

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

On Wed, 2015-10-07 at 11:01 -0700, Walter A. Boring IV wrote: > 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 >

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

On 10/07/2015 03:14 AM, Daniel P. Berrange wrote: For suspended instances, the scenario is really the same as with completely offline instances. The only extra step is that you need to migrate the saved image state file, as well as the disk images. This is trivial once you have done the code

Re: [openstack-dev] [Neutron] [openstack-infra] stable changes to python-neutronclient unable to merge

On 6 October 2015 at 20:06, Armando M. wrote: > Hi folks, > > We are unable to merge stable changes to python-neutronclient (as shown in > [1,2]) because of the missing master fixes [3,4]. We should be able to > untangle Liberty with [5], but to unblock Kilo, I may need to

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

Yes, let's discuss this in Tokyo. Shinobu - Original Message - From: "Clinton Knight" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Thursday, October 8, 2015 2:15:52 AM Subject: Re:

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

Greetings! Our next OpenStack App Catalog meeting will take place this Thursday October 8th at 17:00 UTC in #openstack-meeting-3 The agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog Please add agenda items if there's anything specific you would like to discuss (or

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

On 10/7/2015 6:00 PM, Robert Collins wrote: On 8 October 2015 at 08:38, Matt Riedemann wrote: 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

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

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:

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

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

Re: [openstack-dev] 答复: [Congress] Tokyo sessions

In my memory, there are 4 topics about OPNFV, congress gating, distributed arch, Monasca. Some details in IRC meeting log http://eavesdrop.openstack.org/meetings/congressteammeeting/2015/congressteammeeting.2015-10-01-00.01.log.html 2015-10-08 9:48 GMT+08:00 zhangyali (D)

Re: [openstack-dev] [nova] Intel PCI CI appears lost in the weeds

Hi, mriedem and all Sorry for the CI problem. we now back from holiday now, and find the problem and got solution. CI will be back soon. summary: the LOG server connection lost, so the test result failed to uploading. Yongli He 在 2015年10月08日 07:03, Matt Riedemann 写道: Was seeing

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

> -Original Message- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Wednesday, October 07, 2015 3:48 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [tc] naming N and O releases nowish > > On 10/07/2015 06:22 PM, Monty Taylor wrote: > > On 10/07/2015

[openstack-dev] [all][stable][release] 2015.1.2

Hi, stable/kilo is now frozen. I expect to do a release on Tuesday. If you need to include something please let me know. Thanks chuck __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] Scheduler proposal

On Oct 7, 2015, at 6:00 PM, Chris Friesen wrote: > I've wondered for a while (ever since I looked at the scheduler code, really) > why we couldn't implement more of the scheduler as database transactions. > > I haven't used Cassandra, so maybe you can clarify

Re: [openstack-dev] Scheduler proposal

On 10/07/2015 07:23 PM, Ian Wells wrote: On 7 October 2015 at 16:00, Chris Friesen > wrote: 1) Some resources (RAM) only require tracking amounts. Other resources (CPUs, PCI devices) require tracking allocation of

Re: [openstack-dev] [Fuel] Core Reviewers groups restructure

On Wed, Oct 07, 2015 at 02:04:52PM -0700, Dmitry Borodaenko wrote: > While we're waiting for openstack-infra team to finish the stackforge > migration and review our ACL changes, I implemented the rest of the > changes agreed in this thread: > > - Fuel-core group removed everywhere. > > -

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

I can definitely help. —N. On Oct 7, 2015, at 8:11 PM, Edgar Magana > wrote: Hello, I would like to invite everybody to become an active contributor for the OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

[openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

Hello, I would like to invite everybody to become an active contributor for the OpenStack Networking Guide: http://docs.openstack.org/networking-guide/ During the Liberty cycle we made a lot of progress and we feel that the guide is ready to have even more contributions and formalize a bit

Re: [openstack-dev] Scheduler proposal

On 7 October 2015 at 16:00, Chris Friesen wrote: > 1) Some resources (RAM) only require tracking amounts. Other resources > (CPUs, PCI devices) require tracking allocation of specific individual host > resources (for CPU pinning, PCI device allocation, etc.).

Re: [openstack-dev] Scheduler proposal

On Oct 7, 2015, at 2:28 PM, Zane Bitter wrote: > It seems to me (disclaimer: not a Nova dev) that which database to use is > completely irrelevant to your proposal, Well, not entirely. The difference is that what Cassandra offers that separates it from other DBs is exactly

Re: [openstack-dev] Scheduler proposal

I think if you went ahead and did the experiment, and had good results from it, the discussion would start to progress whether or not folks were fond of Cassandra or ... Thanks, Kevin From: Ed Leafe [e...@leafe.com] Sent: Wednesday, October 07, 2015 5:24

[openstack-dev] 答复: [Congress] Tokyo sessions

Hi Tim, Thanks for informing the meeting information. But does the meeting have some topics scheduled? I think it’s better to know what we are going to talk. Thanks so much! Yali 发件人: Tim Hinrichs [mailto:t...@styra.com] 发送时间: 2015年10月2日 2:52 收件人: OpenStack Development Mailing List (not for

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

On Wed, Oct 07, 2015 at 12:41:55PM -0700, Devananda van der Veen wrote: > 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

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

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

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 > Reply-To: "OpenStack Development Mailing List (not for usage questions)"

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: >

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 >

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

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]

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

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 - >

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 -

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

[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

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

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

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

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

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.

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 - >>

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

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

[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

[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.

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,

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

[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

[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

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 > >

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,

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

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

[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

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 > > >

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

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

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

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,

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

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

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: > >> > >>

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

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

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:

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- >

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,

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

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.

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

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:

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

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

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

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

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 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

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

  1   2   >