Re: [openstack-dev] [heat] convergence cancel messages

Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800: > Hi, > > I would like the discuss various approaches towards fixing bug > https://launchpad.net/bugs/1533176 > > When convergence is on, and if the stack is stuck, there is no way to > cancel the existing request. This feature

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

+1 - sorry for the delay. Taylor Peoples David TARDIVEL wrote on 02/17/2016 08:05:24 AM: > From: David TARDIVEL > To: "openstack-dev@lists.openstack.org" > Date: 02/17/2016 08:05 AM > Subject:

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

Excerpts from Jay Pipes's message of 2016-02-23 16:10:46 -0800: > On 02/22/2016 04:23 AM, Sylvain Bauza wrote: > > I won't argue against performance here. You made a very nice PoC for > > testing scaling DB writes within a single python process and I trust > > your findings. While I would be

Re: [openstack-dev] [heat] Questions on template-validate

On 23-Feb-16 20:34, Jay Dobies wrote: > I am going to bring this up in the team meeting tomorrow, but I figured > I'd send it out here as well. Rather than retype the issue, please look at: > > https://bugs.launchpad.net/heat/+bug/1548856 > > My question is what the desired behavior of

[openstack-dev] [heat] convergence cancel messages

Hi, I would like the discuss various approaches towards fixing bug https://launchpad.net/bugs/1533176 When convergence is on, and if the stack is stuck, there is no way to cancel the existing request. This feature was not implemented in convergence, as the user can again issue an update on an

Re: [openstack-dev] [nova] python-novaclient region setting

fwiw, the second part of Monty's message is in the docs, sans region - it would be a fairly swift change to add that and I'll probably submit a gerrit for it soon. Regards os_client_config, http://docs.openstack.org/developer/os-client-config/ is great. Unfortunately it didn't work for me in this

[openstack-dev] [Neutron] Drivers meeting cancelled Feb 25

Folks, Just a reminder that due to the ongoing Neutron mid-cycle, the drivers team is cancelled for this week. We'll be sending out a report at the end of the week/early next week to keep you abreast of the progress made. Cheers, Armando

[openstack-dev] [release][oslo] oslo.privsep 1.3.0 release (mitaka)

We are tickled pink to announce the release of: oslo.privsep 1.3.0: OpenStack library for privilege separation This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.privsep With package available at:

[openstack-dev] [os-brick][nova][cinder] os-brick/privsep change is done and awaiting your review

Re: https://review.openstack.org/#/c/277224 Most of the various required changes have flushed out by now, and this change now passes the dsvm-full integration tests(*). (*) well, the experimental job anyway. It still relies on a merged-but-not-yet-released change in oslo.privsep so gate + 3rd

Re: [openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

On 18 February 2016 at 10:50, Matt Fischer wrote: > I've been having some issues with keystone v3 and versionless endpoints > and I'd like to know what's expected to work exactly in Liberty and beyond. > I thought with v3 we used versionless endpoints but it seems to cause

Re: [openstack-dev] [magnum] containers across availability zones

Ricardo, Yes, that approach would work. I don’t see any harm in automatically adding tags to the docker daemon on the bay nodes as part of the swarm heat template. That would allow the filter selection you described. Adrian > On Feb 23, 2016, at 4:11 PM, Ricardo Rocha

Re: [openstack-dev] [Congress] Issue with glancev2 datasource driver

Hi Bryan, Could you show me debug log of the command using following command? When I check the command in my stable/liberty, it works well. $ openstack congress datasource row list glancev2 images --debug And if the setting for the driver is valid, it would show you logs about glance driver

Re: [openstack-dev] [tricircle] playing tricircle with devstack under two-region configuration

Hi Joe and Zhiyuan, My VM has recovered. When I re-install devstack in node1, I encounter the following errors. The info in stack.sh.log is as follows: 2016-02-23 11:18:27.238 | Error: Service n-sch is not running 2016-02-23 11:18:27.238 | +

Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Nate, That's right. Initially there wasn't any work done to the Ansible playbooks to turn off Aodh alarming when deploying Ceilometer. Ideally the playbooks would check to see if any alarm hosts are defined. If so, then turn on the Aodh configurations within Ceilometer. If not, then leave

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

On 02/22/2016 04:23 AM, Sylvain Bauza wrote: I won't argue against performance here. You made a very nice PoC for testing scaling DB writes within a single python process and I trust your findings. While I would be naturally preferring some shared-nothing approach that can horizontally scale,

Re: [openstack-dev] [ceilometer] [openstack-ansible] OpenStack-Ansible Ceilometer Configuration

Hi Alex, So it's looking to me like my problem was being caused by openstack-ansible trying to set up aodh although I didn't configure it and didn't want to use it. In ceilometer.conf I found that in the [database] section the metering and event connections were correctly looking for mongodb

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

On 02/23/2016 06:03 PM, Chris Friesen wrote: On 02/21/2016 01:56 PM, Jay Pipes wrote: Yingxin, sorry for the delay in responding to this thread. My comments inline. On 02/17/2016 12:45 AM, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource-provider and

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

On 02/23/2016 06:12 PM, Chris Friesen wrote: On 02/22/2016 03:23 AM, Sylvain Bauza wrote: See, I don't think that a compute node unable to start a request is an 'abnormal case'. There are many reasons why a request can't be honored by the compute node : - for example, the scheduler doesn't

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

On Tue, Feb 23, 2016 at 05:32:44PM -0500, James Slagle wrote: > On Tue, Feb 23, 2016 at 5:18 PM, Devananda van der Veen > wrote: > > Responding to your points out of order, since that makes more sense to me > > right now ... > > > >> Since currently DIB claims to be

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

On 02/22/2016 03:23 AM, Sylvain Bauza wrote: See, I don't think that a compute node unable to start a request is an 'abnormal case'. There are many reasons why a request can't be honored by the compute node : - for example, the scheduler doesn't own all the compute resources and thus can

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

On 02/21/2016 01:56 PM, Jay Pipes wrote: Yingxin, sorry for the delay in responding to this thread. My comments inline. On 02/17/2016 12:45 AM, Cheng, Yingxin wrote: To better illustrate the differences between shared-state, resource-provider and legacy scheduler, I’ve drew 3 simplified

Re: [openstack-dev] [magnum] containers across availability zones

Hi Ricardo, +1 from me. I like this feature. Best regards, Hongbin -Original Message- From: Ricardo Rocha [mailto:rocha.po...@gmail.com] Sent: February-23-16 5:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum] containers across

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

On Tue, Feb 23, 2016 at 5:18 PM, Devananda van der Veen wrote: > Responding to your points out of order, since that makes more sense to me > right now ... > >> Since currently DIB claims to be backwards compatible, we just need to >> leave master backwards compatible with

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

Responding to your points out of order, since that makes more sense to me right now ... Since currently DIB claims to be backwards compatible, we just need to > leave master backwards compatible with Kilo and Liberty Ironic, which > means not deleting the bash ramdisk element. If Ironic wants to

[openstack-dev] [magnum] containers across availability zones

Hi. Has anyone looked into having magnum bay nodes deployed in different availability zones? The goal would be to have multiple instances of a container running on nodes across multiple AZs. Looking at docker swarm this could be achieved using (for example) affinity filters based on labels.

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

> > > > 1) Being able to do a grant with a prefix like > > GRANT all on 'openstack_ci%'.* to openstack_citest > > Then using that prefix in the random db generation. That would at least > limit scope. That seems the easiest to do with the existing infrastructure. > To use this syntax correctly in

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

On Wed, Feb 17, 2016 at 6: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

[openstack-dev] [Congress] Issue with glancev2 datasource driver

I’m running into an issue with the rows provided by the glancev2 driver for congress. There are images defined in glance (see below) but no rows are being returned by congress. Any idea why this might be happening? Below I query Openstack directly, then try to get the same data thru

Re: [openstack-dev] [all] A proposal to separate the design summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/23/2016 09:50 AM, Michael Krotscheck wrote: > Also, it doesn't seem like alternative cost-savings solutions have > been considered. For example, how about we host a summit in a > Not-Top-Tier city for a change? Examples that come to mind are

[openstack-dev] [release][oslo] tooz 1.33.0 release (mitaka)

We are stoked to announce the release of: tooz 1.33.0: Coordination library for distributed systems. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/tooz With package available at: https://pypi.python.org/pypi/tooz

Re: [openstack-dev] [all] A proposal to separate the design summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/23/2016 11:52 AM, Clint Byrum wrote: > I did not attend the first few summits, my first one being the > Boston event, but I did attend quite a few Ubuntu Developer > Summits, which were much more about development discussions, and > almost

Re: [openstack-dev] [all] A proposal to separate the design summit

> > > * would it better to keep the ocata cycle at a more normal length, and > >then run the "contributor events" in Mar/Sept, as opposed to Feb/Aug? > >(again to avoid the August black hole) > > > > Late March is treacherous in the US, as spring break is generally around > the last week

Re: [openstack-dev] [all] A proposal to separate the design summit

Excerpts from Eoghan Glynn's message of 2016-02-22 15:06:01 -0800: > > > Hi everyone, > > > > TL;DR: Let's split the events, starting after Barcelona. > > > > Long long version: > > > > In a global and virtual community, high-bandwidth face-to-face time is > > essential. This is why we made

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

That's what I tried first :) For some reason load distribution was still uneven. I'll check this again, maybe I missed something. On Tue, Feb 23, 2016 at 5:37 PM, Chris Friesen wrote: > On 02/23/2016 05:25 AM, Roman Podoliaka wrote: > >> So looks like it's two

Re: [openstack-dev] [oslo] oslo.db reset session?

On Tue, Feb 23, 2016 at 7:23 PM, Mike Bayer wrote: > Also I'm not > sure how the enginefacade integration with nova didn't already cover this, I > guess it doesn't yet impact all of those existing MySQLOpportunisticTest > classes it has. Yeah, I guess it's the first test case

Re: [openstack-dev] [oslo] oslo.db reset session?

Ok, so I uploaded https://review.openstack.org/#/c/283728/ on the top of Sean's patches. We'll take a closer look tomorrow, if we can just put something like this to oslo.db/sqlalchemy/test_base as a public test fixture. On Tue, Feb 23, 2016 at 7:23 PM, Mike Bayer wrote: > >

Re: [openstack-dev] [nova][cinder] volumes stuck detaching attaching and force detach

On 22 February 2016 at 22:08, Walter A. Boring IV wrote: > On 02/22/2016 11:24 AM, John Garbutt wrote: >> >> Hi, >> >> Just came up on IRC, when nova-compute gets killed half way through a >> volume attach (i.e. no graceful shutdown), things get stuck in a bad >> state,

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/23/2016 12:26 PM, Mike Bayer wrote: >> 2 thoughts on that: >> >> 1) Being able to do a grant with a prefix like >> >> GRANT all on 'openstack_ci%'.* to openstack_citest >> >> Then using that prefix in the random db generation. That would at least >> limit scope. That seems the easiest to do

Re: [openstack-dev] [all] A proposal to separate the design summit

Excerpts from Sean McGinnis's message of 2016-02-22 11:48:50 -0800: > On Mon, Feb 22, 2016 at 05:20:21PM +, Amrith Kumar wrote: > > Thierry and all of those who contributed to putting together this write-up, > > thank you very much. > > > > TL;DR: +0 > > > > Longer version: > > > > While I

[openstack-dev] [cross-project] Meeting SKIPPED, Tue February 23rd, 21:00 UTC

Hi all! We will be skipping the cross-project meeting since there are no agenda items to discuss, but someone can add one [1] to call a meeting next time. Cross-project spec liaisons, please be ready to discuss these specs for next week's meeting: * Support for 4-byte unicode characters in

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/23/2016 12:20 PM, Sean Dague wrote: On 02/23/2016 11:29 AM, Mike Bayer wrote: On 02/22/2016 08:18 PM, Sean Dague wrote: On 02/22/2016 08:08 PM, Davanum Srinivas wrote: Sean, You need to set the env variable like so. See testenv:mysql-python for example

Re: [openstack-dev] [oslo] oslo.db reset session?

On 02/23/2016 12:06 PM, Roman Podoliaka wrote: Mike, I think that won't work as Nova creates its own instance of _TransactionContextManager: https://github.com/openstack/nova/blob/d8ddecf6e3ed1e8193e5f6dba910eb29bbe6dac6/nova/db/sqlalchemy/api.py#L134-L135 Maybe we could change

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/23/2016 11:29 AM, Mike Bayer wrote: > > > On 02/22/2016 08:18 PM, Sean Dague wrote: >> On 02/22/2016 08:08 PM, Davanum Srinivas wrote: >>> Sean, >>> >>> You need to set the env variable like so. See testenv:mysql-python >>> for example >>>

[openstack-dev] [oslo] code changes for Mitaka

Folks, Let's wrap up any code changes needed for Mitaka as quickly as possible. We need to cut final releases by tomorrow. "Final release for non-client libraries: Feb 24" from Doug's email [1] We may need some final tweaking just for catching up to g-r later, but any code changes, we need to

Re: [openstack-dev] [oslo] oslo.db reset session?

Mike, I think that won't work as Nova creates its own instance of _TransactionContextManager: https://github.com/openstack/nova/blob/d8ddecf6e3ed1e8193e5f6dba910eb29bbe6dac6/nova/db/sqlalchemy/api.py#L134-L135 Maybe we could change _TestTransactionFactory a bit, so that it takes a context

Re: [openstack-dev] [openstack-infra] Getting Started Guide

On Tue, Feb 23, 2016 at 1:49 AM, Andreas Jaeger wrote: > On 2016-02-23 04:45, Kenny Johnston wrote: > > * The Product Work Group (PWG) uses the openstack-user-stories > > repository and gerrit to review and produce .rst formatted user > stories > > * The PWG is comprised

Re: [openstack-dev] [kolla][infra] Publishing kolla images to docker-registry.openstack.org

Ricardo, Apologies in lag, I remember reading your email but not answering personally. I thought Michal's response was appropriate but there is a bit more to it. We definitely want to have images for the following events: * Any tag such as a milestone, or release candidate, or release * Nightly

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/22/2016 08:18 PM, Sean Dague wrote: On 02/22/2016 08:08 PM, Davanum Srinivas wrote: Sean, You need to set the env variable like so. See testenv:mysql-python for example OS_TEST_DBAPI_ADMIN_CONNECTION=mysql://openstack_citest:openstack_citest@localhost Thanks, Dims [1]

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/22/2016 08:08 PM, Davanum Srinivas wrote: Sean, You need to set the env variable like so. See testenv:mysql-python for example OS_TEST_DBAPI_ADMIN_CONNECTION=mysql://openstack_citest:openstack_citest@localhost you should not need to set this if you're using the default URL. The

Re: [openstack-dev] [oslo] documentation on using the oslo.db opportunistic test feature

On 02/22/2016 08:02 PM, Sean Dague wrote: Before migrating into oslo.db the opportunistic testing for database backends was pretty simple. Create an openstack_citest@openstack_citest pw:openstack_citest and you could get tests running on mysql. This no longer seems to be the case. this is

Re: [openstack-dev] [oslo] oslo.db reset session?

On 02/23/2016 09:22 AM, Sean Dague wrote: With enginefascade working coming into projects, there seems to be some new bits around oslo.db global sessions. The effect of this on tests is a little problematic. Because it builds global state which couples between tests. I've got a review to use

Re: [openstack-dev] [all] A proposal to separate the design summit

On Tue, Feb 23, 2016 at 10:14:11PM +0800, Qiming Teng wrote: :My take of this is that we are saving the cost by isolating developers :(contributors) from users/customers. I'm a little concerned about this as well. Though presumably at least the PTLs would still attend the User/Ops conference

Re: [openstack-dev] [nova] python-novaclient region setting

On 2/22/2016 8:02 AM, Monty Taylor wrote: On 02/21/2016 11:40 PM, Andrey Kurilin wrote: Hi! `novaclient.client.Client` entry-point supports almost the same arguments as `novaclient.v2.client.Client`. The difference is only in api_version, so you can set up region via

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

On Tue, Feb 23, 2016 at 1:48 AM, Ptacek, MichalX wrote: > Hello again, > > > > In last days I realized that rpm/deb packages from supported platforms are > too old (OSC, python-PROJECTclient,….) > > so I suppose that I should install newer versions not via deb/rpm

Re: [openstack-dev] [all] A proposal to separate the design summit

On Tue, Feb 23, 2016 at 3:40 AM Chris Dent wrote: > > However, it makes me sad to see the continued trend of limiting > in-person gatherings. They are useful as a way of keeping people > aligned with similar goals and approaches to reaching those goals. > Yes, it is

Re: [openstack-dev] [ironic] [stable] iPXE / UEFI support for stable liberty

Thank you for the replies, I have abandon the patches, upon re-review and testing of the case I thought was working I agree that these patches are beyond the scope of what a backport should be. Chris On Tue, Feb 23, 2016 at 6:22 AM, Heck, Joseph wrote: > Morning, > > Just

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

On 02/23/2016 05:25 AM, Roman Podoliaka wrote: So looks like it's two related problems here: 1) the distribution of load between workers is uneven. One way to fix this is to decrease the default number of greenlets in pool [2], which will effectively cause a particular worker to give up new

[openstack-dev] [puppet] [ansible] [docs] Packaging changes about to land for Ubuntu + Neutron/Mitaka

Hi Folks We're about to push the next set of updates into the mitaka-proposed area of the Ubuntu Cloud Archive; these include changes to three neutron agent packages which will have impact on end-users and documentation as well as puppet modules, ansible playbooks, chef cookbooks etc... 1)

Re: [openstack-dev] [puppet] weekly meeting #71

rpad.openstack.org/p/puppet-openstack-weekly-meeting-20160223 > > We'll also have open discussion for bugs & reviews, so anyone is welcome > to join. > > See you there, > Thanks for this quick & effective meeting. You can read the notes: http://eavesdrop.openstack.org/me

[openstack-dev] [heat] Questions on template-validate

I am going to bring this up in the team meeting tomorrow, but I figured I'd send it out here as well. Rather than retype the issue, please look at: https://bugs.launchpad.net/heat/+bug/1548856 My question is what the desired behavior of template-validate should be, at least from a historical

[openstack-dev] [release][openstack] os-client-config 1.16.0 release (mitaka)

We are jubilant to announce the release of: os-client-config 1.16.0: OpenStack Client Configuation Library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/os-client-config With package available at:

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

On 02/22/2016 10:25 PM, Wuhongning wrote: Hi all, There is also a control plane performance issue when we try to catch on the spec of typical AWS limit (200 subnets per router). When a router with 200 subnets is scheduled on a new host, a 30s delay is watched when all data plane setup is

[openstack-dev] [release][oslo] futurist 0.13.0 release (mitaka)

We are amped to announce the release of: futurist 0.13.0: Useful additions to futures, from the future. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/futurist With package available at:

Re: [openstack-dev] [heat][magnum] Magnum gate issue

On 23/02/2016 8:09 AM, Oleksii Chuprykov wrote: > Hi. > I am the author of that change. We decided to revert it > https://review.openstack.org/#/c/283297/ , but unfortunately our gates > are also broken at the moment(by ceilometer). > Sorry about that :( > just an fyi, there was a change in

[openstack-dev] [release][ironic] ironic-lib 1.0.0 release (mitaka)

We are thrilled to announce the release of: ironic-lib 1.0.0: Ironic common library This release is part of the mitaka release series. With package available at: https://pypi.python.org/pypi/ironic-lib For more details, please see below. Changes in ironic-lib 0.5.0..1.0.0

[openstack-dev] [oslo] oslo.db reset session?

With enginefascade working coming into projects, there seems to be some new bits around oslo.db global sessions. The effect of this on tests is a little problematic. Because it builds global state which couples between tests. I've got a review to use mysql connection explicitly for some Nova

Re: [openstack-dev] [ironic] [stable] iPXE / UEFI support for stable liberty

Morning, Just a quick note, there is UEFI booting support within iPXE. You have to invoke a specific build of the binary to get the output, but it's there: make bin-x86_64-efi/snponly.efi Not entirely relevant to the core of the thread, but wanted to share that detail if it's been

Re: [openstack-dev] [all] A proposal to separate the design summit

> >I don't think the proposal removes that opportunity. Contributors > >/can/ still go to OpenStack Summits. They just don't /have to/. I > >just don't think every contributor needs to be present at every > >OpenStack Summit, while I'd like to see most of them present at > >every separated

Re: [openstack-dev] [all] A proposal to separate the design summit

On Mon, Feb 22, 2016 at 10:30:56PM -0500, michael mccune wrote: > On 02/22/2016 11:06 AM, Dmitry Tantsur wrote: > >+1 here. I got an impression that midcycles now usually happen in the > >US. Indeed, it's probably much cheaper for the majority of contributors, > >but would make things worse for

Re: [openstack-dev] [all] tenant vs. project

On 12/02/2016 7:01 AM, Sean Dague wrote: > Ok... this is going to be one of those threads, but I wanted to try to > get resolution here. > > OpenStack is wildly inconsistent in it's use of tenant vs. project. As > someone that wasn't here at the beginning, I'm not even sure which one > we are

Re: [openstack-dev] Versions api always returns the listen address

> > keystone session, and the versions API must be lightweight? > > > > If you put a proxy in front of things you need to also set > > osapi_compute_link_prefix - > > > https://github.com/openstack/nova/blob/d8ddecf6e3ed1e8193e5f6dba910 > > eb29bbe6dac6/nova/api/openstack/common.py#L45-L47 > > > >

Re: [openstack-dev] [nova][neutron][upgrade] Grenade multinode partial upgrade - Nova metadata failure

Hi, I have re-spin the grenade multimode dvr config [1]. In my understanding, this job would install multinode environment, with L3 agent and metadata agent running on subnode. Also to take advantage of this setup: a) Grenade tests should create DVR router as resource, b) the Tempest smoke tests

[openstack-dev] Foundation Sponsorship for tox/pytest Sprint

Since every OpenStack project uses tox, would it be possible to have the foundation donate a little bit to the tox/pytest team to enable a sprint on both projects? There's an IndieGoGo (which seems to be yet another crowdfunding site)

Re: [openstack-dev] [heat][magnum] Magnum gate issue

Hi. I am the author of that change. We decided to revert it https://review.openstack.org/#/c/283297/ , but unfortunately our gates are also broken at the moment(by ceilometer). Sorry about that :( On Tue, Feb 23, 2016 at 12:40 AM, Hongbin Lu wrote: > Hi Heat team, > > > >

Re: [openstack-dev] [OpenStack-Infra][cinder] How to configure the third party CI to be triggered only when jenkins +1

On Mon, Feb 22, 2016 at 7:32 PM, liuxinguo wrote: > Hi, > > > > There is no need to trigger third party CI if a patch does not pass Jenkins > Verify. > > I think there is a way to reach this but I’m not sure how. > > > > So is there any reference or suggestion to configure

Re: [openstack-dev] Versions api always returns the listen address

> On 02/23/2016 06:49 AM, Gyorgy Szombathelyi wrote: > > Hi! > > > > Just noticed by a failing > tempest.api.compute.test_versions.TestVersions.test_get_version_details > test: > > The versions answer of the components always return the listen address of > the corresponding daemon. > > Is this

Re: [openstack-dev] Versions api always returns the listen address

On 02/23/2016 06:49 AM, Gyorgy Szombathelyi wrote: > Hi! > > Just noticed by a failing > tempest.api.compute.test_versions.TestVersions.test_get_version_details test: > The versions answer of the components always return the listen address of the > corresponding daemon. > Is this the intended

Re: [openstack-dev] Versions api always returns the listen address

On Tue, Feb 23, 2016 at 3:49 AM, Gyorgy Szombathelyi < gyorgy.szombathe...@doclerholding.com> wrote: > Hi! > > Just noticed by a failing > tempest.api.compute.test_versions.TestVersions.test_get_version_details > test: > The versions answer of the components always return the listen address of >

[openstack-dev] [Networking-vSphere] - changes in nova compute driver

Hi, In Networking-vSphere (ovsvapp), 'vsphere' is used as nova compute driver. I want to know if there is any modification in the default vsphere driver that is specific to ovsvapp. If yes, can you give an idea about the changes ? If not, then how does vsphere driver get to know port group

[openstack-dev] Versions api always returns the listen address

Hi! Just noticed by a failing tempest.api.compute.test_versions.TestVersions.test_get_version_details test: The versions answer of the components always return the listen address of the corresponding daemon. Is this the intended behavior? I think it should tell the public endpoint, the

Re: [openstack-dev] [all] A proposal to separate the design summit

Thierry, Thanks for writing this up. On 02/22/2016 11:14 PM, Thierry Carrez wrote: > More importantly, it would be set to happen a couple of weeks /before/ > the previous cycle release. There is a lot of overlap between cycles. > Work on a cycle starts at the previous cycle feature freeze, while

Re: [openstack-dev] [all] A proposal to separate the design summit

On Tue, 23 Feb 2016, Thierry Carrez wrote: We can't really prevent people from organizing those anyway :) I just hope social in-person team gatherings will not be needed as much with this split. What may still be needed are mid-cycle "sprints" to achieve specific objectives: those could

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/20/2016 12:38 AM, Morgan Fainberg wrote: > AS a point we are also trying to drop "versioned endpoints" as a thing > from the catalog going forward. Please do not add a "cinderv3" or > "volumev3" entry to the catalog. This is something that enourages adding > for every version a new endpoint.

Re: [openstack-dev] [nova] [all] Excessively high greenlet default + excessively low connection pool defaults leads to connection pool latency, timeout errors, idle database connections / workers

Hi all, I've taken another look at this in order to propose patches to oslo.service/oslo.db, so that we have better defaults for WSGI greenlets number / max DB connections overflow [1] [2], which would be more suitable for DB oriented services like our APIs are. I used the Mike's snippet [3] for

Re: [openstack-dev] [all] A proposal to separate the design summit

Hi ops (cc: devs), I'm writing to you to let you know why I think Thierry's proposal is a good one that probably works better for us than the current situation. The design summit for us at the moment isn't as good as it could be. You turn up, ready to contribute and help out developers with

Re: [openstack-dev] [cinder] adding a new /v3 endpoint for api-microversions

On 02/22/2016 10:22 PM, Sean McGinnis wrote: > On Mon, Feb 22, 2016 at 12:40:48PM +0800, Thomas Goirand wrote: >> >> I'd vote for the extra round trip and implementation of caching whenever >> possible. Using another endpoint is really annoying, I already have >> specific stuff for cinder to setup

Re: [openstack-dev] [all] A proposal to separate the design summit

Eoghan Glynn wrote: Thanks for the proposal, just a few questions: * how would we achieve a "scaled-down design summit in Barcelona"? i.e. what would be the forcing function to ensure fewer contributors attend, given that some people will already be making plans? Exactly how much

Re: [openstack-dev] [all] A proposal to separate the design summit

Henry Nash wrote: On 22 Feb 2016, at 17:45, Thierry Carrez wrote: Amrith Kumar wrote: [...] As a result of this proposal, there will still be four events each year, two "OpenStack Summit" events and two "MidCycle" events. Actually, the OpenStack summit becomes the

Re: [openstack-dev] [rally]how can I give admin role to rally

Hi! Since I don't found such scenario in our upstream repo, I assume that this is your custom plugin and I can propose you several solutions: 1) `nova evacuate` is allowed only for admin user, so you can use admin client in your scenario without changing roles for users. Also,

Re: [openstack-dev] [all] A proposal to separate the design summit

Tim Bell wrote: On 22/02/16 17:27, "John Garbutt" wrote: [...] I am sure there are more questions that will pop up. Like I assume this means there is no ATC free pass to the summit? And I guess a small nominal fee for the contributor meetup (like the recent ops meetup, to

Re: [openstack-dev] [puppet] is puppet-keystone using v3 credentials correctly ?

Hello again, In last days I realized that rpm/deb packages from supported platforms are too old (OSC, python-PROJECTclient,….) so I suppose that I should install newer versions not via deb/rpm packages but as pip packages. This kind of dependency on system packages when trying to install v7