[openstack-dev] [neutron] [ovs] How to update flows in br-tun proactively

Hi guys: The bug has be reported on https://bugs.launchpad.net/neutron/+bug/1541738 The flow in br-tun as below is generated by learning flow, and not updated immediately after vm live migration. Original flow: cookie=0x0, duration=194.884s, table=20, n_packets=0, n_bytes=0,

[openstack-dev] [ceilometer]ceilometer-collector high CPU usage

Hi! Excuse me, if the following question/problem is a basic one, already known problem, or even a bad setup on my side. I just noticed that the most CPU consuming process in an idle OpenStack cluster is ceilometer-collector. When there are only 10-15 samples/minute, it just constantly eats

[openstack-dev] [vitrage] Vitrage meeting minutes

Hi, You can find the meeting minutes of Vitrage meeting: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-17-09.00.html Meeting log: http://eavesdrop.openstack.org/meetings/vitrage/2016/vitrage.2016-02-17-09.00.log.html See you next week, Ifat.

[openstack-dev] [openstack-ansible]Review of Bug "1535536"

Hi All, I recently committed code as a fix for the bug "https://bugs.launchpad.net/openstack-ansible/+bug/1535536”. Jenkins gave a ‘-1’ during the review. Going through the logs I found that the errors are not in the code I committed but from other containers and the original code in

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Michal & Raildo, So the keystone patch (https://review.openstack.org/#/c/270057/ ) is now merged. Do you perhaps have a cinder patch that I could review so we can make sure that this is likely to work with the new projects acting as domains? Currently

Re: [openstack-dev] [neutron] [ovs] How to update flows in br-tun proactively

Hi, JingTing The flow should be updated after the rarp broadcast packet be send by qemu. So I think you should make sure whether the broadcast packet has been send and received by the host. Best regards, Xiao Ma (xi...@cisco.com) 马啸 SDN Architect & OpenStack specialist

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/16/2016 11:30 AM, Doug Hellmann wrote: So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects of projects, and community interactions. Telling a bunch of folks that they "are not OpenStack" even though they

[openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

Hi everyone! Yesterday on the Ironic midcycle we agreed that we would like to remove support for the old bash ramdisk from our code and gate. This, however, pose a problem, since we still support Kilo and Liberty. Meaning: 1. We can't remove gate jobs completely, as they still run on

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Tue, 16 Feb 2016, Doug Hellmann wrote: If we want to do that, we should change the rules because we put the current set of rules in place specifically to encourage more project teams to join officially. We can do that, but that discussion deserves its own thread. (Yeah, that's why I

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/05/2016 07:17 PM, Doug Hellmann wrote: > So, is Poppy "open core"? I think it's a simple answer: no, Poppy is not open core. Poppy is not open core... Is Linux Open Core because you have to buy a processor and ram to run it? Or is Firefox open core because I have to buy service from a

[openstack-dev] [nova] Recovering from Instance from a failed 'resize' Operation

Hi, We have an Openstack installation based on Kilo *(with KVM compute)*. One of the users tried to resize his instance. The operation failed midway because of an Auth exception from Neutron probably during a port binding update. The instance was actually tried to be rescheduled to a new Host

Re: [openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

My preference is option 4, however with a slight difference, and that is that we only apply the DIB cap to the job that¹s testing the bash ramdisk. We can say that the bash ramdisk is deprecated in liberty and will not be receiving any further updates, so we¹re capping the DIB version, but because

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On Wed, 17 Feb 2016, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource- provider and legacy scheduler, I've drew 3 simplified pictures [1] in emphasizing the location of resource view, the location of claim and resource consumption, and the resource

Re: [openstack-dev] Call for papers talk gone astray?

In case anyone else is looking at this: On 16/02/16 17:43, Bailey, Darragh wrote: > Anyone able to help out locate where the talk disappeared to as well as > fixing my profile before the voting closes? Jimmy McArthur has been kind enough to step in and take care of the problem, much

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

And it looks like eventlet 0.18.3 breaks neutron: https://bugs.launchpad.net/neutron/+bug/1546506 Victor Stinner wrote: > Hi, > > I asked eventlet dev to *not* remove a release from PyPI before they did > it, but they ignored me and removed 0.18.0 and 0.18.1 releases from

[openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

A set of CORS patches came out recently that add a ton of content to paste.ini for every project (much of it the same between projects) - https://review.openstack.org/#/c/265415/1 paste.ini is in a really weird space because it's config, ops can change it, so large amounts of complicated things

Re: [openstack-dev] [ceilometer]ceilometer-collector high CPU usage

hi, this seems to be similar to a bug we were tracking in earlier[1]. basically, any service with a listener never seemed to idle properly. based on earlier investigation, we found it relates to the heartbeat functionality in oslo.messaging. i'm not entirely sure if it's because of it or some

Re: [openstack-dev] [kolla] Decision of how to manage stable/liberty from Kolla Midcycle

On Wed, Feb 17, 2016 at 3:15 AM, Steven Dake (stdake) wrote: > Hey folks, > > We held a midcycle Feb 9th and 10th. The full notes of the midcycle are > here: > https://etherpad.openstack.org/p/kolla-mitaka-midcycle > > We had 3 separate ~40 minute sessions on making stable

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Le 17/02/2016 13:43, Henry Gessau a écrit : And it looks like eventlet 0.18.3 breaks neutron: https://bugs.launchpad.net/neutron/+bug/1546506 2 releases, 2 regressions in OpenStack. Should we cap eventlet version? The requirement bot can produce patches to update eventlet, patches which

Re: [openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

On 02/17/2016 06:27 AM, Dmitry Tantsur wrote: > Hi everyone! > > Yesterday on the Ironic midcycle we agreed that we would like to remove > support for the old bash ramdisk from our code and gate. This, however, > pose a problem, since we still support Kilo and Liberty. Meaning: > > 1. We can't

Re: [openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

On 02/17/2016 02:22 PM, John Trowbridge wrote: On 02/17/2016 06:27 AM, Dmitry Tantsur wrote: Hi everyone! Yesterday on the Ironic midcycle we agreed that we would like to remove support for the old bash ramdisk from our code and gate. This, however, pose a problem, since we still support

Re: [openstack-dev] [openstack-ansible]Review of Bug "1535536"

On 02/17/2016 04:33 AM, Sirisha Guduru wrote: > I recently committed code as a fix for the bug > "https://bugs.launchpad.net/openstack-ansible/+bug/1535536”. > Jenkins gave a ‘-1’ during the review. Going through the logs I found that > the errors are not in the code I committed but from other

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: > Le 17/02/2016 13:43, Henry Gessau a écrit : > > And it looks like eventlet 0.18.3 breaks neutron: > > https://bugs.launchpad.net/neutron/+bug/1546506 > > 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

I'd support this, Last known version is https://pypi.python.org/pypi/eventlet/0.17.4 -- Dims On Wed, Feb 17, 2016 at 8:42 AM, Doug Hellmann wrote: > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: >> Le 17/02/2016 13:43, Henry Gessau a écrit : >> >

Re: [openstack-dev] [ceilometer]ceilometer-collector high CPU usage

> > hi, Hi Gordon, > > this seems to be similar to a bug we were tracking in earlier[1]. > basically, any service with a listener never seemed to idle properly. > > based on earlier investigation, we found it relates to the heartbeat > functionality in oslo.messaging. i'm not entirely sure if

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On 02/17/2016 08:42 AM, Doug Hellmann wrote: > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: >> Le 17/02/2016 13:43, Henry Gessau a écrit : >>> And it looks like eventlet 0.18.3 breaks neutron: >>> https://bugs.launchpad.net/neutron/+bug/1546506 >> >> 2 releases, 2

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Le 17/02/2016 12:59, Chris Dent a écrit : On Wed, 17 Feb 2016, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource- provider and legacy scheduler, I've drew 3 simplified pictures [1] in emphasizing the location of resource view, the location of claim and

Re: [openstack-dev] [ceilometer]ceilometer-collector high CPU usage

Hi all, Based on my investigation [1], I believe this is a combined effect of using eventlet and condition variables on Python 2.x. When heartbeats are enabled in oslo.messaging, you'll see polling with very small timeout values. This must not waste a lot of CPU time, still it is kind of

Re: [openstack-dev] [ironic] [tripleo] [stable] Phasing out old Ironic ramdisk and its gate jobs

On 02/17/2016 08:30 AM, Dmitry Tantsur wrote: > On 02/17/2016 02:22 PM, John Trowbridge wrote: >> >> >> On 02/17/2016 06:27 AM, Dmitry Tantsur wrote: >>> Hi everyone! >>> >>> Yesterday on the Ironic midcycle we agreed that we would like to remove >>> support for the old bash ramdisk from our

Re: [openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

+1 > On Feb 17, 2016, at 8:05 AM, David TARDIVEL wrote: > > Team, > > I’d like to promote Vincent Francoise to the core team. Vincent's done a > great work > on code reviewing and has proposed a lot of patchsets. He is currently the > most active > non-core

[openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

Team, I'd like to promote Vincent Francoise to the core team. Vincent's done a great work on code reviewing and has proposed a lot of patchsets. He is currently the most active non-core reviewer on Watcher project, and today, he has a very good vision of Watcher. I think he would make an

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Henry, I know about two patches related: Fixes cinder quota mgmt for keystone v3 - https://review.openstack.org/#/c/253759 Split out NestedQuotas into a separate driver - https://review.openstack.org/#/c/274825 The first one was abandoned, so I think the second patch is enough to fix this issue.

Re: [openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

+2 Jean-Emile DARTOIS {P} Software Engineer Cloud Computing {T} +33 (0) 2 56 35 8260 {W} www.b-com.com De : Joe Cropper Envoyé : mercredi 17 février 2016 15:06 À : OpenStack Development Mailing List (not

[openstack-dev] [release] git-upstream 0.11.0 release

Pleased to announce the 0.11.0 release of git-upstream. With source available at: http://git.openstack.org/cgit/openstack/git-upstream Please report any issues through launchpad: https://bugs.launchpad.net/git-upstream git-upstream is an open source Python application that can be

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: > On 02/16/2016 11:30 AM, Doug Hellmann wrote: > > So I think the project team is doing everything we've asked. We > > changed our policies around new projects to emphasize the social > > aspects of projects, and community

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > On Tue, 16 Feb 2016, Doug Hellmann wrote: > > > If we want to do that, we should change the rules because we put > > the current set of rules in place specifically to encourage more > > project teams to join officially. We can do

Re: [openstack-dev] [Fuel][library] Switching to external fixtures for integration Noop tests

Hello, an update inline! On 27.01.2016 17:37, Bogdan Dobrelya wrote: > On 26.01.2016 22:18, Kyrylo Galanov wrote: >> Hello Bogdan, >> >> I hope I am not the one of the context. Why do we separate fixtures for >> Noop tests from the repo? >> I can understand if while noop test block was carried

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Vladimir, a dedicated repo - good to hear. Do you have a rough estimate for how long this directory will be in freeze state? Thanks, Fabrizio > On Feb 15, 2016, at 5:16 PM, Vladimir Kozhukalov > wrote: > > Dear colleagues, > > I'd like to announce that we are next

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

I did push a speculative patch which would address this by not exposing the lookup by int id backdoor - https://review.openstack.org/#/c/281277/ - the results were better than I expected. Andrey, is this going to negatively impact the openstack/ec2 project at all if we do it? -Sean On

[openstack-dev] [openstack-ansible] network question and documentation

Hi, after a first test architecture of openstack (juno then upgrade to kilo), installed from scratch, and because we use Ansible in our organization, we decided to deploy our next openstack generation architecture from the project openstack-ansible. I studied your documentation (very good

[openstack-dev] [ironic] midcycle voice channel is 7778

Hi, We've moved the midcycle to channel 7778 on the infra conferencing system - something is wrong with (no audio coming through). /me lets infra know as well // jim __ OpenStack Development Mailing List (not for

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > On 02/17/2016 08:42 AM, Doug Hellmann wrote: > > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: > >> Le 17/02/2016 13:43, Henry Gessau a écrit : > >>> And it looks like eventlet 0.18.3 breaks neutron: >

Re: [openstack-dev] [ironic] midcycle voice channel is 7779

So, someone has injected their hold music into 7778. We've now moved to 7779, sorry for the trouble :( // jim On Wed, Feb 17, 2016 at 07:01:22AM -0800, Jim Rollenhagen wrote: > Hi, > > We've moved the midcycle to channel 7778 on the infra conferencing > system - something is wrong with (no

[openstack-dev] [Ironic] Heads up: Third Party CI systems

Hi, This email is just a heads up to the people working on 3rd Party CI systems for Ironic. There's a patch in the review queue now [0] that may break you guys (the fix is simple). The patch is adding the ability to deploy nodes using the {pxe, agent}_ipmitool drivers with VMs. But, the problem

[openstack-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies

Fuelers It seems that this change [0] into Fuel came unnoticed, but it may help you in testing your puppet catalogues. I was refactoring our code pieces that actually wait for Load Balancer to be ready to serve requests. I ended putting things into a special define called `wait_for_backend`.

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: > On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > > > On 02/17/2016 08:42 AM, Doug Hellmann wrote: > > > Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100: > > >> Le 17/02/2016 13:43,

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On Wed, 17 February 2016, Sylvain Bauza wrote Le 17/02/2016 12:59, Chris Dent a écrit : On Wed, 17 Feb 2016, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource- provider and legacy scheduler, I've drew 3 simplified pictures [1] in emphasizing the location

Re: [openstack-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies

On 17.02.2016 16:23, Vladimir Kuklin wrote: > Fuelers > > It seems that this change [0] into Fuel came unnoticed, but it may help > you in testing your puppet catalogues. > > I was refactoring our code pieces that actually wait for Load Balancer > to be ready to serve requests. I ended putting

Re: [openstack-dev] [ceilometer]ceilometer-collector high CPU usage

Hi all, I did some more debugging with pdb, and seems to be the problem somehow connected to this eventlet issue: https://github.com/eventlet/eventlet/issues/30 I don't have a clue if it has any connections to the Rabbit heartbeat thing, but if I change the self.wait(0) to self.wait(0.1) in

Re: [openstack-dev] [Nova][API] Does nova API allow the server_id parem as DB index?

On Wed, Feb 17, 2016 at 8:49 AM, Sean Dague wrote: > I did push a speculative patch which would address this by not exposing > the lookup by int id backdoor - https://review.openstack.org/#/c/281277/ > - the results were better than I expected. > > Andrey, is this going to

Re: [openstack-dev] [Watcher] Nominating Vincent Francoise to Watcher Core

+1 On Wed, Feb 17, 2016 at 3:07 PM, Jean-Émile DARTOIS < jean-emile.dart...@b-com.com> wrote: > +2 > > > Jean-Emile > DARTOIS > > {P} Software Engineer > Cloud Computing > {T} +33 (0) 2 56 35 8260 > {W} www.b-com.com > -- > *De :* Joe Cropper >

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

(sorry, quoting off-context, but I feel it's a side point, not the main discussion) Le 17/02/2016 16:40, Cheng, Yingxin a écrit : IMHO, the authority to allocate resources is not limited by compute nodes, but also include network service, storage service or all other services which have

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Doug Hellmann wrote: > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: >> >>> On 02/17/2016 08:42 AM, Doug Hellmann wrote: Excerpts from Victor Stinner's message of 2016-02-17

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

On Wed, 17 February 2016, Sylvain Bauza wrote (sorry, quoting off-context, but I feel it's a side point, not the main discussion) Le 17/02/2016 16:40, Cheng, Yingxin a écrit : IMHO, the authority to allocate resources is not limited by compute nodes, but also include network service, storage

[openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

Greetings, (Note: cross-posted between rdo-list and openstack-dev to reach a larger audience) Today, because of the branding and the name "RDO Manager", you might think that it's something other than TripleO - either something entirely different or perhaps with downstream patches baked in. You

[openstack-dev] [OpenStackClient] New core team members

I would like to announce the addition of Richard Theis and Tang Chen to the OpenStackClient core team. They both have been contributing quality reviews and code for some time now, particularly in the areas of SDK integration and new Network commands. Thank you Richard and Tang for your work and

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

> This requires the loss of all of the features in the newer version of fuel since it relies on the older version of the serialized data from nailgun. Yes. But isn't it how "stable" branches are supposed to work? Introducing new features into "stable" branches will make them not so "stable",

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1. There are already arguably too many names involved in OpenStack, let alone having multiple names for the same thing. :) Thanks, Kevin From: rdo-list-boun...@redhat.com [rdo-list-boun...@redhat.com] on behalf of David Moreau Simard [d...@redhat.com]

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that and

Re: [openstack-dev] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1, I will also add for reference, that there is no other project in RDO that is renamed/rebranded. In fact, even the TripleO packages in RDO have the same naming as the upstream projects. On 02/17/2016 11:27 AM, David Moreau Simard wrote: > Greetings, > > (Note: cross-posted between rdo-list

[openstack-dev] [fuel] Supporting multiple Openstack versions

> So we'll have tons of conditionals in composition layer, right? Even if > some puppet-openstack class have just one new parameter in new release, > then we'll have to write a conditional and duplicate class declaration. Or > write complex parameters hash definitions/merges and use >

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an openstack-specific version that automatically initializes

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

+1 On 2/16/16, 12:52 PM, "Ade Lee" wrote: >+1 > >On Mon, 2016-02-15 at 11:45 -0600, Douglas Mendizábal wrote: >> Hi All, >> >> I would like to nominate Fernando Diaz for the Barbican Core team. >> Fernando has been an enthusiastic contributor since joining the >> Barbican

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

Excerpts from Chris Dent's message of 2016-02-17 17:00:00 +: > On Wed, 17 Feb 2016, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

Excerpts from Michael Krotscheck's message of 2016-02-17 17:26:57 +: > We (that is, the cores, contributors, and consumers that I've been > collaborating with over the past year on this) came to the consensus that > leaving the cors middleware as generic & configurable as possible was >

[openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Fuel core reviewers, Fuel CI is being migrated to an ISO image with Mitaka packages, please don't merge any commits to any Fuel repositories without coordination with Aleksandra until further notice. This merge freeze is expected to last a few hours. -- Dmitry Borodaenko

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Fuelers I have strong opinion against this merge freeze right now. We have critical bugs blocking bvt and we do not have enough info on mitaka readiness for other scenarios than bvt. 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko" < dborodae...@mirantis.com> написал: > Fuel core

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1 it fuels the confusion that RDO Manager has downstream-only patches which is not the case anymore. And I'll bite anyone who will try to sneak downstream-only patches in RDO package of tripleO. Regards, H. __ OpenStack

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 8:38 AM Aleksandr Didenko wrote: > > This requires the loss of all of the features in the newer version of > fuel since it relies on the older version of the serialized data from > nailgun. > > Yes. But isn't it how "stable" branches are supposed to

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > Doug Hellmann wrote: > > Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: > >> On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague wrote: > >> > >>> On 02/17/2016 08:42 AM,

Re: [openstack-dev] [keystone][cinder] Projects acting as a domain at the top of the project hierarchy

Hi all, I discussed the change with other cores in -keystone and, looking at the API change guidelines, it should be an allowed API change. I had a doubt whether the rule "Changing or removing a property in a resource representation." could make it a forbidden API change or not. However, since

[openstack-dev] [fuel][nailgun][volume-manager][fuel-agent] lvm metadata size value. why was it set to 64M?

Hi, Apparently, nailgun assumes that lvm metadata size is always set to 64M [1] It seems that it was defined here since the early beginning of nailgun as a project, therefore it's impossible to figure out for what purposes that was done as early commit messages are not so informative. According

Re: [openstack-dev] [OpenStackClient] New core team members

Congrats to both Richard Theis and Tang Chen -- very well deserved!!! Thank you for guarding the gate! stevemar From: Dean Troyer To: OpenStack Development Mailing List Date: 2016/02/17 11:34 AM Subject:

Re: [openstack-dev] [nova] A prototype implementation towards the "shared state scheduler"

Excerpts from Cheng, Yingxin's message of 2016-02-14 21:21:28 -0800: > Hi, > > I've uploaded a prototype https://review.openstack.org/#/c/280047/ to testify > its design goals in accuracy, performance, reliability and compatibility > improvements. It will also be an Austin Summit Session if

Re: [openstack-dev] [fuel] Supporting multiple Openstack versions

On Wed, Feb 17, 2016 at 9:29 AM Bogdan Dobrelya wrote: > > So we'll have tons of conditionals in composition layer, right? Even if > > some puppet-openstack class have just one new parameter in new release, > > then we'll have to write a conditional and duplicate class

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Doug Hellmann wrote: > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: >> Doug Hellmann wrote: >>> Excerpts from Morgan Fainberg's message of 2016-02-17 07:10:34 -0800: On Wed, Feb 17, 2016 at 5:55 AM, Sean Dague

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

BVT for master has been unblocked earlier today, and a custom ISO with Mitaka packages is passing BVT, so switching to Mitaka will not regress Fuel CI deployment tests. Lets not make this process more complicated than it has to be, non-BVT swarm regressions will have to be fixed either way, and it

[openstack-dev] [release][keystone] pycadf 2.1.0 release (mitaka)

We are satisfied to announce the release of: pycadf 2.1.0: CADF Library This release is part of the mitaka release series. With source available at: https://git.openstack.org/cgit/openstack/pycadf With package available at: https://pypi.python.org/pypi/pycadf Please report issues

Re: [openstack-dev] [fuel] Merge freeze for CI switch to Mitaka

Vladimir, Obviously, there will be regressions in other scenarios. However, it's better to catch them now. We have not much time before FF, and it'd be better to merge such features as early as possible, and do not wait for merge hell a day before FF. The thing we need to know is that BVT is

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

To use the parallel of the Linux OS again, what Linux user doesn't use a vendor (distro) to deploy their machine? Sure, you can linux from scratch it, but who does but for education/entertainment purposes? Yes, its important to be able to do it without a vendor. The same way its important to

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

Hi Fabrizio, The project-config patch is on the review now, waiting for a core-reviewers to merge the changes. On Wed, Feb 17, 2016 at 5:47 PM, Fabrizio Soppelsa wrote: > Vladimir, > a dedicated repo - good to hear. > Do you have a rough estimate for how long this

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 03:10 AM, Sean M. Collins wrote: > Thomas Goirand wrote: >> s/I dislike/is not free software/ [*] >> >> It's not a mater of taste. Having Poppy requiring a non-free component, >> even indirectly (ie: the Oracle JVM that CassandraDB needs), makes it >> non-free. > > Your definition

[openstack-dev] [release][keystone] keystoneauth1 2.3.0 release (mitaka)

We are satisfied to announce the release of: keystoneauth1 2.3.0: Authentication Library for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystoneauth With package available at:

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On 02/17/2016 09:30 AM, Doug Hellmann wrote: Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: On 02/16/2016 11:30 AM, Doug Hellmann wrote: So I think the project team is doing everything we've asked. We changed our policies around new projects to emphasize the social aspects

Re: [openstack-dev] [Congress] Nominating Masahito for core

Thank you folks. I'm glad to be a part of this team and community, and appreciate all supports from you. On 2016/02/17 12:10, Anusha Ramineni wrote: +1 Best Regards, Anusha On 17 February 2016 at 00:59, Peter Balland > wrote: +1

Re: [openstack-dev] [infra][neutron] publish and update Gerrit dashboard link automatically

Hi all, I automated a non-dashboard version of Rossella’s script. The tweaked script that gets run: https://review.openstack.org/#/c/281446/ Results, updated hourly (bookmarkable, will redirect to gerrit): http://104.236.79.17/ http://104.236.79.17/current http://104.236.79.17/current-min

[openstack-dev] [release][keystone] keystonemiddleware 4.3.0 release (mitaka)

We are eager to announce the release of: keystonemiddleware 4.3.0: Middleware for OpenStack Identity This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/keystonemiddleware With package available at:

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On 02/17/2016 09:28 AM, Doug Hellmann wrote: Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: A reason _I_[1] think we need to limit things is because from the outside OpenStack doesn't really look like anything that you can put a short description on. It's more murky than that

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes wrote: > On 02/17/2016 09:30 AM, Doug Hellmann wrote: > >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: >> >>> On 02/16/2016 11:30 AM, Doug Hellmann wrote: >>> So I think the project team is doing everything

[openstack-dev] [release][stable][oslo] oslo.service 0.9.1 release (liberty)

We are chuffed to announce the release of: oslo.service 0.9.1: oslo.service library This release is part of the liberty stable release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service With package available at:

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

Excerpts from Anne Gentle's message of 2016-02-17 12:28:42 -0600: > On Wed, Feb 17, 2016 at 12:20 PM, Jay Pipes wrote: > > > On 02/17/2016 09:30 AM, Doug Hellmann wrote: > > > >> Excerpts from Mike Perez's message of 2016-02-17 03:21:51 -0800: > >> > >>> On 02/16/2016 11:30

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: > On 02/17/2016 09:28 AM, Doug Hellmann wrote: > > Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +: > >> A reason _I_[1] think we need to limit things is because from the > >> outside OpenStack doesn't really look like

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

You should be able to test that the functionality of using the api, and seeing an appropriate plugin call gets called without a proprietary back end. Then its up to each plugin to test for their own compliance to the reference. Another approach for testing, maybe you could create the "dead

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

On Wed, Feb 17, 2016 at 9:41 AM Doug Hellmann wrote: > > The next release of oslo.config will have this. > https://review.openstack.org/#/c/278604/ http://stjent.pinnaclecart.com/images/products/preview/55008.jpg Michael

Re: [openstack-dev] [oslo] upgrade implications of lots of content in paste.ini

I am very much against adding extra data to paste-ini especially config data that is consumed by the applications. I generally understand why it was implemented in the way it has. The oslo_config change that Doug linked will make this need mostly go away however. I would like to move us towards

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

Excerpts from Henry Gessau's message of 2016-02-17 13:00:03 -0500: > Doug Hellmann wrote: > > Excerpts from Henry Gessau's message of 2016-02-17 11:00:53 -0500: > >> Doug Hellmann wrote: > >>> Excerpts from Morgan Fainberg's message of 2016-02-17

[openstack-dev] [heat] intrinsic function bugfixes and hot versioning

Hi all, So, Zane and I have discussed $subject and it was suggested I take this to the list to reach consensus. Recently, I've run into a couple of small but inconvenient limitations in our intrinsic function implementations, specifically for str_replace and repeat, both of which did not behave

Re: [openstack-dev] [Rdo-list] [TripleO] Should we rename "RDO Manager" to "TripleO" ?

+1 This has been very confusing and it would be nice to finally get that clearer. On Wed, Feb 17, 2016 at 7:49 PM, Haïkel wrote: > +1 it fuels the confusion that RDO Manager has downstream-only patches > which is not the case anymore. > > And I'll bite anyone who will

[openstack-dev] [oslo][doc][all] Removal of deprecate oslo.og log_format configuration option

The deprecated log_format option is being removed [1] This option can be found across many projects generally in sample configuration files [2]. These should be automatically removed if these files are auto generated via oslo-config-generator or in sphinx generated documentation. In other

Re: [openstack-dev] [all] [tc] unconstrained growth, why?

On Wed, 17 Feb 2016, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-02-17 13:25:58 -0500: I think we are doing a bad job of communicating the product vs. kit nature of OpenStack. Yeah, I tend to think that's it, too. I'll concede to that and agree we can and should do

  1   2   >