Re: [openstack-dev] OpenStack-Announce List

On 14/01/16 15:22, Andreas Jaeger wrote: On 2016-01-14 08:13, Tom Fifield wrote: So, I'm prompted by another 20 oslo release emails to dredge up this thread :) There appears to be broad consensus that those shouldn't be going to the announce list ... what do we need to do to get that to change

Re: [openstack-dev] OpenStack-Announce List

On 2016-01-14 08:13, Tom Fifield wrote: So, I'm prompted by another 20 oslo release emails to dredge up this thread :) There appears to be broad consensus that those shouldn't be going to the announce list ... what do we need to do to get that to change to posted to "-dev + batched inside the we

Re: [openstack-dev] OpenStack-Announce List

So, I'm prompted by another 20 oslo release emails to dredge up this thread :) There appears to be broad consensus that those shouldn't be going to the announce list ... what do we need to do to get that to change to posted to "-dev + batched inside the weekly -dev digest from thingee" as Thi

Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

From: "Armando M." mailto:arma...@gmail.com>> Reply-To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, January 12, 2016 at 8:57 PM To: OpenStack List mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron]{l2-gateway] is this project alive

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

In Nova the alternate meetings were chaired by different people. I think that was very productive and fruitful. So it is certainly something worth considering. At the end of the day all of the meetings are logged and people can go over the logs and address issues that can and may concern them. A

[openstack-dev] [ceilometer] ceilometer meter-list output is empty

Hi, I have installed a devstack environment with ceilometer enabled: enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer I am trying to run some ceilometer commands to test whether my ceilometer is working well and get to know ceilometer as well. But, no matter how m

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 10:47:21PM +, Sean M. Collins wrote: > On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: > > One of the ideas that I have been thinking about over the last month or two > > is do we > > Want to create a dedicated library file in devstack to support compilati

[openstack-dev] [release][oslo] taskflow release 1.26.0 (mitaka)

We are delighted to announce the release of: taskflow 1.26.0: Taskflow structured state management library. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/taskflow With package available at: https://pypi.python.org/

[openstack-dev] [release][oslo] oslo.vmware release 2.2.1 (mitaka)

We are tickled pink to announce the release of: oslo.vmware 2.2.1: Oslo VMware library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware With package available at: https://pypi.python.org/pypi/oslo.vmware

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

We are overjoyed to announce the release of: oslo.service 1.3.0: oslo.service library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.service With package available at: https://pypi.python.org/pypi/oslo.service

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

We are thrilled to announce the release of: oslo.privsep 0.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: https://pypi.python.o

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

We are gleeful to announce the release of: oslo.versionedobjects 1.3.0: Oslo Versioned Objects library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.versionedobjects With package available at: https://pypi.pyt

[openstack-dev] [release][oslo] debtcollector release 1.2.0 (mitaka)

We are tickled pink to announce the release of: debtcollector 1.2.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. This release is part of the mitaka release series. With source available at: http://git.ope

[openstack-dev] [release][oslo] oslo.log release 2.3.0 (mitaka)

We are tickled pink to announce the release of: oslo.log 2.3.0: oslo.log library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.log With package available at: https://pypi.python.org/pypi/oslo.log Please repor

[openstack-dev] [release][oslo] oslo.utils release 3.4.0 (mitaka)

We are amped to announce the release of: oslo.utils 3.4.0: Oslo Utility library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.utils With package available at: https://pypi.python.org/pypi/oslo.utils Please re

[openstack-dev] [release][oslo] oslo.config release 3.2.1 (mitaka)

We are pumped to announce the release of: oslo.config 3.2.1: Oslo Configuration API This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.config With package available at: https://pypi.python.org/pypi/oslo.config Ple

[openstack-dev] [release][oslo] oslo.cache release 1.2.0 (mitaka)

We are stoked to announce the release of: oslo.cache 1.2.0: Cache storage for Openstack projects. This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.cache With package available at: https://pypi.python.org/pypi/osl

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

We are overjoyed to announce the release of: oslo.reports 1.3.0: oslo.reports library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.reports With package available at: https://pypi.python.org/pypi/oslo.reports

[openstack-dev] [release][oslo] oslo.middleware release 3.5.0 (mitaka)

We are happy to announce the release of: oslo.middleware 3.5.0: Oslo Middleware library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.middleware With package available at: https://pypi.python.org/pypi/oslo.mid

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

We are delighted to announce the release of: oslo.policy 1.3.0: Oslo Policy library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.policy With package available at: https://pypi.python.org/pypi/oslo.policy Ple

[openstack-dev] [release][oslo] oslo.db release 4.3.0 (mitaka)

We are thrilled to announce the release of: oslo.db 4.3.0: Oslo Database library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.db With package available at: https://pypi.python.org/pypi/oslo.db Please report

[openstack-dev] [release][oslo] oslo.i18n release 3.2.0 (mitaka)

We are jazzed to announce the release of: oslo.i18n 3.2.0: Oslo i18n library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.i18n With package available at: https://pypi.python.org/pypi/oslo.i18n Please report

[openstack-dev] [release][oslo] oslo.concurrency release 3.3.0 (mitaka)

We are satisfied to announce the release of: oslo.concurrency 3.3.0: Oslo Concurrency library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.concurrency With package available at: https://pypi.python.org/pypi/o

[openstack-dev] [release][oslo] oslo.context release 1.0.1 (mitaka)

We are thrilled to announce the release of: oslo.context 1.0.1: Oslo Context library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/oslo.context With package available at: https://pypi.python.org/pypi/oslo.context

[openstack-dev] [QA] Meeting Thursday January 14th at 9:00 UTC

Hello everyone, Please reminder that the weekly OpenStack QA team IRC meeting will be Thursday, Jan 14th at 9:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_January_14th_2016_.2809

Re: [openstack-dev] [glance] allow a ranking mechanism for glance-api to order image locations

Hi Jake, Thanks for raising this topic. I'm really interested in it. I reviewed most of the locations patches of Glance, so drop my 2 cents about this. So firstly, I think it's a valid user case. As for the implementation, I think a spec-lite is enough, given it's just a driver for current lo

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 01/14/2016 03:49 AM, Sean M. Collins wrote: On Wed, Jan 13, 2016 at 02:59:35AM CST, Ihar Hrachyshka wrote: Kevin Benton wrote: The issue with this data is that who says something is not a good metric. For example, this shows that I attended more than twice as many afternoon meetings as t

[openstack-dev] [neutron][L3] Wrong fail over of HA-Router

Hi All Could you give me some advice for our problem? We use Neutron L3-HA. When I associate/disassociate floating-ip, the state of ha keepalived become MASTER/MASTER state. Then Because at that time,the sending of vrrp packet from MASTER to BACKUP stop for 40 seconds. I checked logs of Keepaliv

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 2016-01-14 12:32:02 +1300 (+1300), Robert Collins wrote: [...] > We tried to add some unit test jobs to cross check constraints, but we > need some infrastructure work to permit specifying that a unit test > job for a change to requirements checkout the code for e.g. nova and > run nova's tests.

Re: [openstack-dev] [api][all] api variation release by release

Thanks for pointing the history out, Matt. According to this thread, I feel the NOTE of each release maximum microversion will help for users because many clouds are deployed from certain releases. https://review.openstack.org/#/c/267247/ is doing that. Thanks Ken Ohmichi 2016-01-13 11:55 GMT+0

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

> While I don't think it's strictly required by the api change guidelines [3] > I think the API interactions and behavior here feel different enough to > warrant > having a microversion. Ideally there should have been some versioning in the > cinder api around the multiattach support but that ship

[openstack-dev] [glance] allow a ranking mechanism for glance-api to order image locations

Hi all, I've recently ran across a constraint in glance-api while working with image locations. In essence, there is no way to customize ordering of image-locations other than the default location strategies, namely location_order and store_type [0]. It seems like a more generic method of ordering

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

On Wed, Jan 13, 2016 at 04:52:37PM -0600, Matt Riedemann wrote: > tl;dr - do we need a REST API microversion for multi-attach support in nova? Yes, I think so > > The details: > > The volume multi-attach series in nova, starting here [1], has run into an > upgrade problem. > > Basically, there

[openstack-dev] [networking guide meeting] Meeting Tomorrow!

Hi, Kind reminder email that we have our networking guide team meeting tomorrow Thursday at 16:00 UTC in #openstack-meeting Agenda: https://wiki.openstack.org/wiki/Documentation/NetworkingGuide/Meetings Cheers, Edgar __ O

Re: [openstack-dev] [Neutron] Gate failure

This fix failed to merge, due to a new regression in how another job is using dib. Here's a non voting patch for that, until it gets debugged: https://review.openstack.org/267223 The fail stack is now two deep. Doug > On Jan 13, 2016, at 11:41 AM, Armando M. wrote: > > It's the usual time

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 10:47:21PM +, Sean M. Collins wrote: > On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: > > One of the ideas that I have been thinking about over the last month or two > > is do we > > Want to create a dedicated library file in devstack to support compilati

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 14 January 2016 at 08:24, Carl Baldwin wrote: > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper-constraints.txt file. This is great progress and I applaud it. > I'll continue to cheer on this

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

Hi Jamie, I would like to clarify several things. First, a container uuid is intended to be unique globally (not within individual cluster). If you create a container with duplicated uuid, the creation will fail regardless of its bay. Second, you are in control of the uuid of the container tha

Re: [openstack-dev] [oslo][osdk] PrettyTable needs a home in OpenStack

On 11 January 2016 at 10:27, Doug Hellmann wrote: > ... > > > There are a few libraries on the list, too (automaton, ironic-lib), and > that's confusing. It would be interesting to know how they're using > table output. > > Doug > > As far as ironic-lib goes, I took a look. It isn't using PrettyT

[openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

tl;dr - do we need a REST API microversion for multi-attach support in nova? The details: The volume multi-attach series in nova, starting here [1], has run into an upgrade problem. Basically, there is code in liberty which doesn't pass an instance uuid and volume id to the block_device_mapp

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 04:47:19PM CST, Sean M. Collins wrote: > I'd prefer to see small, very specific DevStack plugins that have narrow > focus, and jobs that need them for specific things adding them to their > local.conf settings explicitly via enable_repo lines. Sorry, enable_plugin lines -

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: > One of the ideas that I have been thinking about over the last month or two > is do we > Want to create a dedicated library file in devstack to support compilation > and installation > Of ovs. So, my suggestion is as follows: creat

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

On Wed, Jan 13, 2016 at 12:11:27PM +0100, Thierry Carrez wrote: > One possible solution here would be to check if the meetings currently > scheduled on your ideal slots are actually still using the spot, as there > are a non-trivial amount of dead meetings around. You can ping me on IRC so > that

Re: [openstack-dev] [all] re-introducing twisted to global-requirements

On 8 January 2016 at 08:09, Jim Rollenhagen wrote: > Hi all, > > A change to global-requirements[1] introduces mimic, which is an http > server that can mock various APIs, including nova and ironic, including > control of error codes and timeouts. The ironic team plans to use this > for testing py

Re: [openstack-dev] Shovel (RackHD/OpenStack)

Hey Jay! (yeah, I’m here and lurking in the corners, albeit with a different email at the moment) Yep - RackHD was created by a company that was acquired by EMC to attack the lowest-level of hardware automation. EMC was interesting in pushing that into Open Source, and surprisingly I was completel

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

> -Original Message- > From: Russell Bryant [mailto:rbry...@redhat.com] > Sent: Wednesday, January 13, 2016 9:19 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron] Testing Neutron with latest OVS > > On 01/13/2016 03:59 PM, Assaf

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 01/13/2016 03:41 PM, Armando M. wrote: > > > On 13 January 2016 at 11:24, Carl Baldwin > wrote: > > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

On 01/13/2016 03:59 PM, Matt Riedemann wrote: > I'm formally proposing that the nova-stable-maint team [1] adds Tony > Breeds to the core team. > > I don't have a way to track review status on stable branches, but there > are review numbers from gerrit for stable/liberty [2] and stable/kilo [3]. >

Re: [openstack-dev] [puppet] list of blockers to deploy mitaka

On 01/13/2016 03:41 PM, Emilien Macchi wrote: > A quick update. > > CentOS jobs are all green. > Ubuntu jobs are green for scenario002 and red for scenario001 because of > [1] which will be resolved on Thursday 14th. > > The only remaining blocker is [2] and [3]. > > Please help to review thes

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

On 01/13/2016 04:42 AM, Jamie Hannaford wrote: I've recently been gathering feedback about the Magnum API and one of the things that people commented on​ was the global /containers endpoints. One person highlighted the danger of UUID collisions: """ It takes a container ID which is intended to

Re: [openstack-dev] Shovel (RackHD/OpenStack)

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Wednesday, January 13, 2016 8:53 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] Shovel (RackHD/OpenStack) > > On 01/13/2016 03:28 PM, Keedy, Andre wrote: > > Hi All, I'm pleased to annou

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/13/2016 03:59 PM, Assaf Muller wrote: > On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar wrote: >> Hi all, >> >> recently I was working on firewall driver [1] that requires latest >> features in OVS, specifically conntrack support. In order to get the >> driver tested, we need to have the lat

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

I’m pretty new to openstack-ansible-security but based on my use cases which are as much About using this for verification as they are for building secure boxes my preference would be 3) Use an Ansible callback plugin to catch these and print them at the end of the playbook run -Rob On 13

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Wed, Jan 13, 2016 at 4:50 AM, Jakub Libosvar wrote: > Hi all, > > recently I was working on firewall driver [1] that requires latest > features in OVS, specifically conntrack support. In order to get the > driver tested, we need to have the latest OVS kernel modules on machines > running tests

[openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

I'm formally proposing that the nova-stable-maint team [1] adds Tony Breeds to the core team. I don't have a way to track review status on stable branches, but there are review numbers from gerrit for stable/liberty [2] and stable/kilo [3]. I know that Tony does a lot of stable branch reviews

Re: [openstack-dev] [nova][libvirt] VIR_MIGRATE_NON_SHARED_INC works more like full copy in block migration ?

On 01/12/2016 05:35 AM, Kashyap Chamarthy wrote: On Sun, Jan 10, 2016 at 06:07:33PM +0800, Luo Gangyi wrote: Hi devs, Do you test the difference between within and without VIR_MIGRATE_NON_SHARED_INC ? When I add VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in nova, nova block migratio

Re: [openstack-dev] Shovel (RackHD/OpenStack)

On 01/13/2016 03:28 PM, Keedy, Andre wrote: Hi All, I’m pleased to announce a new application called ‘Shovel ‘that is now available in a public repository on GitHub (https://github.com/keedya/Shovel). Shovel is a server with a set of APIs that wraps around RackHD/Ironic’s existing APIs allowing

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 13 January 2016 at 11:24, Carl Baldwin wrote: > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper-constraints.txt file. This is great progress and I applaud it. > I'll continue to cheer on this

Re: [openstack-dev] [puppet] list of blockers to deploy mitaka

A quick update. CentOS jobs are all green. Ubuntu jobs are green for scenario002 and red for scenario001 because of [1] which will be resolved on Thursday 14th. The only remaining blocker is [2] and [3]. Please help to review these patches so we can bump our CI to Mitaka OpenStack codebase. [1]

[openstack-dev] Shovel (RackHD/OpenStack)

Hi All, I'm pleased to announce a new application called 'Shovel 'that is now available in a public repository on GitHub (https://github.com/keedya/Shovel). Shovel is a server with a set of APIs that wraps around RackHD/Ironic's existing APIs allowing users to find Baremetal Compute nodes that

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

Join us tomorrow for our weekly meeting, January 14th at 17:00UTC in #openstack-meeting-3. The agenda can be found here, and please add to it if you want to get something on the agenda: https://wiki.openstack.org/wiki/Meetings/app-catalog Tomorrow we hope to have someone from Mistral joining to d

Re: [openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

Some random thoughts... I've been looking into how to log our production docker containers better, and a couple of things have shown up that may be of interest to you... 1, docker now has a journald backend. so rather then log to files, you just set your daemons to log to stdout, and docker+jou

Re: [openstack-dev] [Heat] Status of the Support Conditionals in Heat templates

On 12/15/2015 12:07 PM, Fox, Kevin M wrote: My $0.02: heat as it is today, requires all users to be devops, and to carefully craft the templates launched specific to the cloud and the particular app they are trying to write. Making sharing code between heat users difficult. This means the potent

[openstack-dev] [Cinder] [Ironic] Attach Cinder Volume to the Ironic Instance without Nova Step-by-Step guide

Hi team, In scope of 'use-cinder-without-nova' blueprint [1] I've created PoC code [2] with detailed instructions how to attach volumes inside Ironic or Nova instances. Detailed instructions could be found on my blog [3]. Any feedback are welcome! [1] https://github.com/openstack/cinder-specs/b

[openstack-dev] [zuul][infra] Synchronizing state of Zuul with Gerrit

Today we had a change [0] that somehow weren't being picked up by Zuul to gate queue although it had Workflow+1 and Verified+1. Only after I added another Workflow+1 it did get Zuul's attention. I don't know what exactly happen, but it seems Zuul didn't notice (lost) either initial Verified+1 or Wo

Re: [openstack-dev] [api][all] api variation release by release

On 01/12/2016 09:55 PM, Matt Riedemann wrote: Nova and Ironic already support microversioned APIs. Cinder and Neutron are working on it I think, and there could be others. just as a heads up, sahara is also working towards implementing microversions in its next api[1] regards, mike [1]: htt

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

- Orijinal Mesaj - > Kimden: "Markus Zoeller" > Kime: "OpenStack Development Mailing List (not for usage questions)" > > Gönderilenler: 13 Ocak Çarşamba 2016 17:38:21 > Konu: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > Esra Celik wrote on 01/13/2016 01:29:12 P

[openstack-dev] Further closing the holes that let gate breakage happen

Hi, I was looking at the most recent gate breakage in Neutron [1], fixed by [2]. This gate breakage was held off for some time by the upper-constraints.txt file. This is great progress and I applaud it. I'll continue to cheer on this effort. Now to the next problem. If my assessment of this

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

On Tue, 2016-01-12 at 20:47 +, Steven Hardy wrote: > Hi all, > > I've noticed that we have a fairly large number of unused parameters > in > t-h-t, some of which are marked deprecated, some aren't. > > Since we moved tripleoclient to use parameter_defaults everywhere, I > think > it should be

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

- Original Message - > On Wed, 2016-01-13 at 04:41 -0500, Tzu-Mainn Chen wrote: > > Hey all, > > > > I realize now from the title of the other TripleO/Mistral thread [1] > > that > > the discussion there may have gotten confused.  I think using Mistral > > for > > TripleO processes that ar

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On Wed, Jan 13, 2016 at 02:59:35AM CST, Ihar Hrachyshka wrote: > Kevin Benton wrote: > > >The issue with this data is that who says something is not a good metric. > >For example, this shows that I attended more than twice as many afternoon > >meetings as the morning meetings when I know I actual

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On Wed, Jan 13, 2016 at 12:01 PM, Armando M. wrote: > > > On 12 January 2016 at 20:07, Kyle Mestery wrote: > >> On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley < >> doug...@parksidesoftware.com> wrote: >> >>> I don’t think it ninja merged. It had plenty of reviews, and was open >>> during internat

Re: [openstack-dev] [Neutron] Team meeting on Tuesday 1400UTC

On 12 January 2016 at 20:07, Kyle Mestery wrote: > On Tue, Jan 12, 2016 at 5:28 PM, Doug Wiegley < > doug...@parksidesoftware.com> wrote: > >> I don’t think it ninja merged. It had plenty of reviews, and was open >> during international hours. I don’t have any issue there. >> >> I don’t like the

[openstack-dev] [Neutron] Gate failure

It's the usual time of the week where I submit the dreaded email Please do not push anything in the queue until change [1] merges. Cheers, Armando [1] https://review.openstack.org/#/c/266885/ __ OpenStack Development Mai

[openstack-dev] [release][keystone] keystoneauth release 2.2.0 (mitaka)

We are eager to announce the release of: keystoneauth 2.2.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: https://pypi.python.o

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

We are tickled pink to announce the release of: keystonemiddleware 4.1.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: https://pypi.p

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

On 01/13/2016 10:31 AM, Chris Dent wrote: > On Wed, 13 Jan 2016, Sean Dague wrote: > >> Because this regex is built from a dictionary, hash seed matters, and it >> is not stable which will get precedence. > > Ow[1]. > >> I'd like to propose for Nova we restrict project_id in the URL to >> [0-9a-

[openstack-dev] [sahara] Sahara scenario tests freeze

Hi folks, please, stop merging scenario tests CRs to the scenario tests, their unit tests and scenarios itself. We're now in progress of moving them to the separated repository. Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engi

Re: [openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

On 01/13/2016 10:43 AM, Kerr, Andrew wrote: > Hi all, > > The physical equipment that runs the NetApp CI system is scheduled to be > moved to a new building next week. In order to accommodate this move we will > be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to > have

[openstack-dev] [Cinder] [Manila] NetApp CI will be offline next week

Hi all, The physical equipment that runs the NetApp CI system is scheduled to be moved to a new building next week. In order to accommodate this move we will be taking the NetApp CI system offline at EOB on Friday Jan 15 and plan to have it back up and running by EOB on Monday Jan 25. I just

Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th

Esra Celik wrote on 01/13/2016 01:29:12 PM: > From: Esra Celik > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 01/13/2016 01:30 PM > Subject: Re: [openstack-dev] [nova] config options: IRC meeting at Jan. 11th > > > > I do also realize now that I didn't make yo

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

On Wed, 13 Jan 2016, Sean Dague wrote: Because this regex is built from a dictionary, hash seed matters, and it is not stable which will get precedence. Ow[1]. I'd like to propose for Nova we restrict project_id in the URL to [0-9a-f]+, which is any valid hex string. Ints are a subset of thi

[openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hey there, After presenting openstack-ansible-security at the Security Project Mid-Cycle meeting yesterday, the question came up around how to handle situations where automation might cause problems. For example, the STIG requires[1] that all sys

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

Hello guys, So 2 cents from me: As sdake said, Heka seems to be replacement of rsyslog rather than logstash. If it can replace both, even better, we end up with one less dependency, and less dependencies are good. So I'd rather wait with making this decision before Eric presents PoC he promised he

[openstack-dev] [nova] wrong disk usage for volume-backed instances

Hello, This issue has been active since mid 2014 and still hasn't got any resolution or fixes merged. I'm pushing for a fix to this issue and anybody with help or feedback is welcome. Please see my last comment on https://bugs.launchpad.net/nova/+bug/1469179 regarding the old review which could b

Re: [openstack-dev] [Manila] Midcycle meetup

https://etherpad.openstack.org/p/manila-mitaka-midcycle Clinton On 1/13/16, 9:51 AM, "Luis Pabon" wrote: >Is there a link to the topics or schedule? > >- Luis > >- Original Message - >From: "Ben Swartzlander" >To: "OpenStack Development Mailing List (not for usage questions)" > >Sent:

Re: [openstack-dev] [Manila] Midcycle meetup

https://etherpad.openstack.org/p/manila-mitaka-midcycle On Wed, Jan 13, 2016 at 4:51 PM, Luis Pabon wrote: > Is there a link to the topics or schedule? > > - Luis > > - Original Message - > From: "Ben Swartzlander" > To: "OpenStack Development Mailing List (not for usage questions)" < >

[openstack-dev] [neutron] [QoS] Phantom meeting

Hi everybody, We held a short meeting today because the calendar was saying today we had another biweekly meeting, regardless of having another one last week. So I guess next week we have no meeting unless we want to have another short one too. Minutes are here: http://eavesdrop

Re: [openstack-dev] [Manila] Midcycle meetup

Is there a link to the topics or schedule? - Luis - Original Message - From: "Ben Swartzlander" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Wednesday, December 9, 2015 8:25:55 PM Subject: Re: [openstack-dev] [Manila] Midcycle meetup On 12/04/2015 04:42 PM,

Re: [openstack-dev] [nova] path forward on making project_id optional in API URLs

As a note, there is potential that this will require older deployments that have historical names migrated to update project IDs to hex-strings. These are a minority of deployments at best, but this should be considered in the proposal so if this goes forward we can clearly communicate this change

Re: [openstack-dev] [api][all] api variation release by release

On 1/13/2016 12:11 AM, joehuang wrote: Thanks for the information, it's good to know the documentation. The further question is whether there is any XML format like document will be published for each release and all core projects, so that other cloud management software can read the changes

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

This needs to be proposed as a spec, not just a blueprint. For what it is worth, this has been discussed many times and it was determined that keystone as a project was not interested in really managing the life cycle of passwords on this front. Since we support the use of real Identity Stores and

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

A standard method of rate limiting for OpenStack services would be a good thing to figure out. On Jan 13, 2016 02:56, "Jordan Pittier" wrote: > Hi, > Can't you just do some rate limiting at your webserver level ? > > On Tue, Jan 12, 2016 at 3:55 PM, McPeak, Travis > wrote: > >> One issue to be a

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Wed, 2016-01-13 at 04:41 -0500, Tzu-Mainn Chen wrote: > Hey all, > > I realize now from the title of the other TripleO/Mistral thread [1] > that > the discussion there may have gotten confused.  I think using Mistral > for > TripleO processes that are obviously workflows - stack deployment, > n

[openstack-dev] [nova] path forward on making project_id optional in API URLs

There is a snag at the moment in making project_id optional in API URLs because of how python routes modules works. When we call mapper.resource(...) it's creating a series of mapper.connect(...) calls to setup routes. This just adds items to a dictionary. When we later use the mapper to match a r

Re: [openstack-dev] App dev guides update [nova] [keystone] [cinder] [swift] [glance] [neutron] [trove] [heat] [manila] [ceilometer] [sahara] [senlin]

Anne, thank you for this update. And thank you to the contributors who improved the SDK and developer guide documentation. Fantastic work, all of you! Best, -jay On 01/13/2016 12:18 AM, Anne Gentle wrote: Hi all, I wanted to be sure to post to the dev, docs, and user mailing lists about the p

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

From: David Moreau Simard mailto:d...@redhat.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, January 13, 2016 at 5:55 AM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack

[openstack-dev] [Monasca] Add Monasca Client to global reqs

Guys, I just updated the requirements patch to update the monasca client to the global reqs. It now points to the latest version 1.0.27 that has all the compatible libraries (thanks Joe). https://review.openstack.org/#/c/251674/ Please review it so we can merge it. Thanks, Fabio ___

[openstack-dev] Add Monasca Client to global reqs

Guys, I just updated the requirements patch to update the monasca client to the global reqs. It now points to the latest version 1.0.27 that has all the compatible libraries (thanks Joe). https://review.openstack.org/#/c/251674/ Please review it so we can merge it. Thanks, Fabio ___

[openstack-dev] [Oslo][all] os-profiler under Oslo umbrella

Team, Oslo folks have voted[1] to be the home for the osprofiler project[2]. Several projects are already using osprofiler. One example of work in flight is for Nova[3]. Please take a look at the README to see the features/description, in a nutshell it will allow operators / end users to drill do

  1   2   >