Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

I agree with Jay. The extension layer is also expensive in CPU usage, and it also makes more difficult to troubleshoot issues. - Original Message - > From: "Jay Pipes" > To: "OpenStack Development Mailing List" , > "Sergey Nikitin" > > Sent: Sunday, March 8, 2015 1:31:34 AM > Subject:

Re: [openstack-dev] Ideas about Openstack Cinder for GSOC 2015

On Sat, Feb 28, 2015 at 7:52 AM, Jay Bryant wrote: > Fyi ... > > This is something that Mike Perez was thinking about so you can ping thingee > on irc if you can't find e0ne. I would, thanks very much ;-) Harry __ OpenStac

Re: [openstack-dev] Ideas about Openstack Cinder for GSOC 2015

On Sat, Feb 28, 2015 at 6:10 AM, Ivan Kolodyazhny wrote: > Hi Harry, Hi e0ne, > > Please, ping me in IRC (e0ne) if you are still in Cinder as a part of GSoC. > I am sorry I reply a little late, I would contact you in IRC ;-) Thanks, Harry _

Re: [openstack-dev] [Fuel] Testing DB migrations

Hi, guys, Indeed, it's a hot topic since it looks like there's no silver bullet at all. As OpenStack community, we should move toward oslo.db approach, but it may require hard effort from our side. Meantime, as a part of bp/consume-external-ubuntu [1] I've prepared a base class for testing migrat

[openstack-dev] IPAM reference driver status and other stuff

Aloha everybody! This is another long email, so here's the summary for people with 5-minute or less attention span: The IPAM reference driver is almost ready [1]. Unfortunately letting the driver doing allocation pools required a few major changes, so the latest patchset is rather big. I would li

Re: [openstack-dev] [all][log] Log Working Group priorities

Hi, I would really like to help make these logging improvements a reality. On 5 March 2015 at 12:13, Kuvaja, Erno wrote: > We had our first logging workgroup meeting [1] yesterday where we agreed 3 > main priorities for the group to focus on. This time really doesn't work for me I am afraid, cl

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 03/07/2015 07:31 PM, Jay Pipes wrote: > Hi Stackers, > > Now that microversions have been introduced to the Nova API (meaning we > can now have novaclient request, say, version 2.3 of the Nova API using > the special X-OpenStack-Nova-API-Version HTTP header), is there any good > reason to requi

Re: [openstack-dev] [all] SQLAlchemy performance suite and upcoming features (was: [nova] blueprint about multiple workers)

- Original Message - > From: "Mike Bayer" > To: "Attila Fazekas" > Cc: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Friday, March 6, 2015 2:20:45 AM > Subject: Re: [openstack-dev] [all] SQLAlchemy performance suite and upcoming > features (was: [nova] bl

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Hi, Apologies for the slow reply, long weekend because of a public holiday over here. I'm probably going to end up repeating part of what Alex has mentioned as well. So the first thing I think we want to distinguish between plugins being a REST API user or operator concept and it being a tool de

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Mon, Mar 9, 2015 at 9:35 PM, Sean Dague wrote: > On 03/07/2015 07:31 PM, Jay Pipes wrote: > > Hi Stackers, > > > > Now that microversions have been introduced to the Nova API (meaning we > > can now have novaclient request, say, version 2.3 of the Nova API using > > the special X-OpenStack-Nov

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

Hi, I think I agree with Jay here, but let me explain... On 8 March 2015 at 12:10, Alex Xu wrote: > Thanks for Jay point this out! If we have agreement on this and document it, > that will be great for guiding developer how to add new API. +1 Please could you submit a dev ref for this? We can

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Mon, Mar 9, 2015 at 10:08 PM, John Garbutt wrote: > Hi, > > I think I agree with Jay here, but let me explain... > > On 8 March 2015 at 12:10, Alex Xu wrote: > > Thanks for Jay point this out! If we have agreement on this and document > it, > > that will be great for guiding developer how to

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Mon, Mar 9, 2015 at 10:08 PM, John Garbutt wrote: > +1 > > Please could you submit a dev ref for this? > > We can argue on the review, a bit like this one: > > https://github.com/openstack/nova/blob/master/doc/source/devref/policy_enforcement.rst > > I think it'd also be a good idea to add a t

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

- Original Message - > From: "Christopher Yeoh" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, March 9, 2015 1:04:15 PM > Subject: Re: [openstack-dev] [nova][api] Microversions. And why do we need > API extensions for new API functionality? >

Re: [openstack-dev] [horizon] Do No Evil

On Sun, Mar 8, 2015 at 3:21 PM Thomas Goirand wrote: > > Anyway, you understood me: please *never* use this Expat/MIT license > with the "The Software shall be used for Good, not Evil." additional > clause. This is non-free software, which I will *never* be able to > upload to Debian (and Canonic

[openstack-dev] [api][neutron] Best API for generating subnets from pool

Greetings! Neutron is adding a new concept of "subnet pool". To put it simply, it is a collection of IP prefixes from which subnets can be allocated. In this way a user does not have to specify a full CIDR, but simply a desired prefix length, and then let the pool generate a CIDR from its prefixes

[openstack-dev] [murano] how can deploy environment with useEnvironmentNerwork=false

hi there In murano when deploy environment useEnvironmentNerwork=true is default. How can I deploy with useEnvironmentNerwork=true? I'm currently using sample Apache web server package -- Choe, Cheng-Dae Blog: http://blog.woosum.net

[openstack-dev] [swift] auth migration and user data migration

hi, I have a standalone swift cluster with swauth as the auth module. By standalone, I mean the cluster is not in the context of OpenStack, or keystone server. Now I have moved ACL logic to application level and decided to have all data in swift under one user account. I have a few questions on t

Re: [openstack-dev] [horizon] Do No Evil

On 03/09/2015 01:59 PM, Michael Krotscheck wrote: > On Sun, Mar 8, 2015 at 3:21 PM Thomas Goirand > wrote: > > > Anyway, you understood me: please *never* use this Expat/MIT license > with the "The Software shall be used for Good, not Evil." additional > claus

[openstack-dev] [heat][qa] Forward plan for heat scenario tests

Since test_server_cfn_init was recently moved from tempest to the heat functional tests, there are no subclasses of OrchestrationScenarioTest. If there is no plan to add any more heat scenario tests to tempest I would like to remove that class. So I want to confirm that future scenario tests wil

[openstack-dev] [tooz] 1.0 goals

Hi fellow developers, It'd be nice to achieve a 1.0 release for tooz, as some projects are already using it, and more are going to adopt it. I think we should collect features and potential bugs/limitations we'd like to have and fix before that. Ideas, thoughts? Cheers, -- Julien Danjou ;; Free

[openstack-dev] [all] cliff 1.10.1 release

The Oslo team is chuffed to announce the release of: cliff 1.10.1: Command Line Interface Formulation Framework For more details, please see the git log history below and: https://launchpad.net/python-cliff/+milestone/1.10.1 Please report issues through launchpad: https://bugs.launchpa

[openstack-dev] [all] oslo.concurrency 1.7.0 release

The Oslo team is pleased to announce the release of: oslo.concurrency 1.7.0: oslo.concurrency library For more details, please see the git log history below and: http://launchpad.net/oslo.concurrency/+milestone/1.7.0 Please report issues through launchpad: http://bugs.launchpad.net/osl

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

Boris, 1. Suppose a project say Nova wants to enable this Rally Integration for its functional tests, what does that project have to do? (other than the existing well defined tox targets) 2. Is there a "test" project with Gabbi based tests that you know of? 3. What changes if any are needed in Gab

[openstack-dev] [all] oslo.config 1.9.1 release

The Oslo team is glad to announce the release of: oslo.config 1.9.1: Oslo Configuration API For more details, please see the git log history below and: http://launchpad.net/oslo.config/+milestone/1.9.1 Please report issues through launchpad: http://bugs.launchpad.net/oslo.config Notab

[openstack-dev] [Fuel] Logstash and grok patterns

Dear All, I have a openstack HA environment deployed using fuel 5.1. Fuel master node collects all the node logs under /var/log/docker-logs/remote/ directory. I have installed Logstash on fuel master node. Here is Logstash.conf: http://paste.openstack.org/show/190985/ Here is rsyslog Template f

Re: [openstack-dev] [horizon] Do No Evil

On Sun, Mar 08, 2015 at 11:19:10PM +0100, Thomas Goirand wrote: > On 03/08/2015 06:34 PM, Mike Bayer wrote: > > > > > > Ian Wells wrote: > > > >> With apologies for derailing the question, but would you care to tell us > >> what evil you're planning on doing? I find it's always best to be >

[openstack-dev] [all] oslo.db 1.6.0 release

The Oslo team is thrilled to announce the release of: oslo.db 1.6.0: oslo.db library For more details, please see the git log history below and: http://launchpad.net/oslo.db/+milestone/1.6.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.db Notable changes

[openstack-dev] [all] oslo.i18n 1.5.0 release

The Oslo team is gleeful to announce the release of: oslo.i18n 1.5.0: oslo.i18n library For more details, please see the git log history below and: http://launchpad.net/oslo.i18n/+milestone/1.5.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.i18n Notable chang

[openstack-dev] [all] oslo.log 1.0.0 release

The Oslo team is excited to announce the release of: oslo.log 1.0.0: oslo.log library For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Notable changes -

Re: [openstack-dev] [heat][qa] Forward plan for heat scenario tests

On Mon, Mar 09, 2015 at 09:52:54AM -0400, David Kranz wrote: > Since test_server_cfn_init was recently moved from tempest to the heat > functional tests, there are no subclasses of OrchestrationScenarioTest. > If there is no plan to add any more heat scenario tests to tempest I would > like to remo

[openstack-dev] [all] oslo.messaging 1.8.0 release

The Oslo team is overjoyed to announce the release of: oslo.messaging 1.8.0: Oslo Messaging API For more details, please see the git log history below and: http://launchpad.net/oslo.messaging/+milestone/1.8.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.messag

[openstack-dev] [all] oslo.middleware 1.0.0 release

The Oslo team is gleeful to announce the release of: oslo.middleware 1.0.0: Oslo Middleware library For more details, please see the git log history below and: http://launchpad.net/oslo.middleware/+milestone/1.0.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.m

[openstack-dev] [all] oslo.rootwrap 1.6.0 release

The Oslo team is chuffed to announce the release of: oslo.rootwrap 1.6.0: Oslo Rootwrap For more details, please see the git log history below and: http://launchpad.net/oslo.rootwrap/+milestone/1.6.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.rootwrap Notab

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

Davanum, 1. Suppose a project say Nova wants to enable this Rally Integration > for its functional tests, what does that project have to do? (other > than the existing well defined tox targets) Actually project by it self shouldn't do anything. The whole work regarding to integration belongs t

[openstack-dev] [all] oslo.serialization 1.4.0 release

The Oslo team is chuffed to announce the release of: oslo.serialization 1.4.0: oslo.serialization library For more details, please see the git log history below and: http://launchpad.net/oslo.serialization/+milestone/1.4.0 Please report issues through launchpad: http://bugs.launchpad.n

[openstack-dev] [all] oslo.utils 1.4.0 release

The Oslo team is gleeful to announce the release of: oslo.utils 1.4.0: Oslo Utility library For more details, please see the git log history below and: http://launchpad.net/oslo.utils/+milestone/1.4.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.utils Notable

[openstack-dev] [all] oslotest 1.5.1 release

The Oslo team is happy to announce the release of: oslotest 1.5.1: OpenStack test framework For more details, please see the git log history below and: http://launchpad.net/oslotest/+milestone/1.5.1 Please report issues through launchpad: http://bugs.launchpad.net/oslotest Notable cha

[openstack-dev] [all] stevedore 1.3.0 release

__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] stevedore 1.3.0 release

The Oslo team is excited to announce the release of: stevedore 1.3.0: Manage dynamic plugins for Python applications For more details, please see the git log history below and: https://launchpad.net/python-stevedore/+milestone/1.3.0 Please report issues through launchpad: https://bugs.

[openstack-dev] [all] too 0.13.0 release

The Oslo team is pumped to announce the release of: tooz 0.13.0: Coordination library for distributed systems. For more details, please see the git log history below and: http://launchpad.net/python-tooz/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.ne

[openstack-dev] [Tempest] isolation default config change notification

Hi All, This is follow up on [1]. Running the full tempest test-suite in parallel without the allow_tenant_isolation=True settings, can cause random not too obvious failures, which caused lot of issue to tempest newcomers. There are special uses case when you might want to disable it, for examp

Re: [openstack-dev] [horizon] Do No Evil

On Mon, Mar 9, 2015, at 08:52 AM, Radomir Dopieralski wrote: > On 03/09/2015 01:59 PM, Michael Krotscheck wrote: > > On Sun, Mar 8, 2015 at 3:21 PM Thomas Goirand > > wrote: > > > > > > Anyway, you understood me: please *never* use this Expat/MIT license > > wit

[openstack-dev] [QA] Tempest Configuration Guide

Hi Everyone, I just wanted to mention that in the past couple of weeks we've started an effort to write some documentation to explain common aspects of tempest configuration. The current version of the doc can be found here: http://docs.openstack.org/developer/tempest/configuration.html Right no

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

On Mon, 9 Mar 2015, Davanum Srinivas wrote: 2. Is there a "test" project with Gabbi based tests that you know of? In addition to the ceilometer tests that Boris pointed out gnocchi is using it as well: https://github.com/stackforge/gnocchi/tree/master/gnocchi/tests/gabbi 3. What changes

Re: [openstack-dev] [Tempest] isolation default config change notification

On Mon, Mar 09, 2015 at 10:47:21AM -0400, Attila Fazekas wrote: > Hi All, > > This is follow up on [1]. > Running the full tempest test-suite in parallel without the > allow_tenant_isolation=True settings, can cause random not too obvious > failures, which caused lot of issue to tempest newcomers

Re: [openstack-dev] [neutron] How neutron calculate routing path

- Original Message - > The L3 agent uses ARP and static routes like a normal router would. The L2 > agent is where there might be differences depending on the network type > used. If it's a tunnel overlay, the L2 agent may perform an ARP offload from > information it has learned via the L

Re: [openstack-dev] [neutron] Neutron agent internal data structures

- Original Message - > Thank you. I am looking to read this state and compare it with neutron DB. If > there are agents that do it already, I would like only to learn if I can > change the polling period. Can you advise about the most efficient way to > learn which agent does it and which

Re: [openstack-dev] [swift] auth migration and user data migration

> On Mar 9, 2015, at 9:46 AM, Weidong Shao wrote: > > hi, > > I have a standalone swift cluster with swauth as the auth module. By > standalone, I mean the cluster is not in the context of OpenStack, or > keystone server. That's completely fine (and not uncommon at all). > > Now I have mov

[openstack-dev] [TripleO] Fedora 21 support

I've been chipping away at what it would take to upgrade our Fedora CI jobs to Fedora 21. The motivation was primarily that Fedora 21 has more recent packages which would simplify some of the package requirements in Delorean. Besides this Fedora 21 has been out for months now so we really should be

Re: [openstack-dev] [all] too 0.13.0 release

Apologies to the tooz team, auto-correct ate the Z in the name in the subject line. - Doug On Mon, Mar 9, 2015, at 09:44 AM, Doug Hellmann wrote: > The Oslo team is pumped to announce the release of: > > tooz 0.13.0: Coordination library for distributed systems. > > For more details, please see

Re: [openstack-dev] [tooz] 1.0 goals

Let's do it, One that I can think of off the top of my head would be to have `join_group` and associated functions have the ability to automatically create the group if it does not exist already (instead of raising a error and then having the user deal with the failure themselves). I'm also

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

ok, no problem, will take a look it tomorrow. 2015-03-09 20:18 GMT+08:00 Christopher Yeoh : > > > On Mon, Mar 9, 2015 at 10:08 PM, John Garbutt > wrote: > >> +1 >> >> Please could you submit a dev ref for this? >> >> We can argue on the review, a bit like this one: >> >> https://github.com/opens

Re: [openstack-dev] [tooz] 1.0 goals

Another idea; provide some way for tooz to handle the heartbeating (instead of clients having to do this); perhaps tooz coordinator should take ownership of the thread that heartbeats (instead of clients having to do this on there own)? This avoids having each client create there own thread (or

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On 03/08/2015 02:28 PM, Morgan Fainberg wrote: On March 8, 2015 at 11:24:37 AM, David Stanek ([email protected] ) wrote: On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer>wrote: can you elaborate on your reasoning that FK constraints should

[openstack-dev] [Infra] Meeting Tuesday March 10th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday March 10th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interest

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Excerpts from David Stanek's message of 2015-03-08 11:18:05 -0700: > On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: > > > can you elaborate on your reasoning that FK constraints should be used less > > overall? or do you just mean that the client side should be mirroring the > > same > > rule

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Wei D wrote: > +1, > > > > I am fan of checking the constraints in the controller level instead of > relying on FK constraints itself, thanks. Why shouldn’t the storage backends, be they relational or not, be tasked with verifying integrity of data manipulations? If data integrity rules a

[openstack-dev] [Fuel] Recent issues with our review workflow

Hi All, I've noticed a few times recently where reviews have been abandoned by people who were not the original authors. These reviews were only days old and there was no prior notice or discussion. This is both rude and discouraging to contributors. Reasons for abandoning should be discussed on t

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Sun, Mar 8, 2015 at 10:28 PM, Chen, Wei D wrote: > +1, > > > > I am fan of checking the constraints in the controller level instead of > relying on FK constraints itself, thanks. > The Keystone controllers shouldn't do any business logic. This should be in the managers. The controllers should

Re: [openstack-dev] [nova] Request non-priority feature freeze exception for VIF_TYPE_TAP

On 02/25/2015 07:07 AM, Daniel P. Berrange wrote: > On Wed, Feb 25, 2015 at 11:46:05AM +, Neil Jerram wrote: >> Although we are past the non-priority deadline, I have been encouraged >> to request this late exception for Project Calico's spec and code adding >> VIF_TYPE_TAP to Nova. > > I'm af

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Clint Byrum wrote: > Excerpts from David Stanek's message of 2015-03-08 11:18:05 -0700: >> On Sun, Mar 8, 2015 at 1:37 PM, Mike Bayer wrote: >> >>> can you elaborate on your reasoning that FK constraints should be used less >>> overall? or do you just mean that the client side should be mirr

Re: [openstack-dev] Missing button to send Ctrl+Alt+Del for SPICE Console

On 03/05/2015 09:34 AM, Andy McCrae wrote: > Sorry to resurrect this almost a year later! I've recently run into this > issue, and it does make logging into Windows instances, via the console, > quite challenging. > > On Fri, Jun 6, 2014 at 3:46 PM, Ben Nemec wrote: > >> This sounds like a reaso

Re: [openstack-dev] [tooz] 1.0 goals

Julien Danjou wrote: On Mon, Mar 09 2015, Joshua Harlow wrote: One that I can think of off the top of my head would be to have `join_group` and associated functions have the ability to automatically create the group if it does not exist already (instead of raising a error and then having the us

Re: [openstack-dev] [tooz] 1.0 goals

On Mon, Mar 09 2015, Joshua Harlow wrote: > One that I can think of off the top of my head would be to have `join_group` > and associated functions have the ability to automatically create the group if > it does not exist already (instead of raising a error and then having the user > deal with the

[openstack-dev] [all] debtcollector 0.3.0 release

The Oslo team is glad to announce the release of: debtcollector 0.3.0: A collection of Python deprecation patterns and strategies that help you collect your technical debt in a non- destructive manner. For more details, please see the git log history below and: http://launchpad.net/debtcoll

Re: [openstack-dev] [tooz] 1.0 goals

On Mon, Mar 09 2015, Joshua Harlow wrote: > Another idea; provide some way for tooz to handle the heartbeating (instead of > clients having to do this); perhaps tooz coordinator should take ownership of > the thread that heartbeats (instead of clients having to do this on there > own)? > This avo

[openstack-dev] [api] metadata and tagging guidelines up for review

Hi all, I would like to invite you to review the guidelines for metadata and tagging that I proposed to the API-WG. Links: https://review.openstack.org/#/c/141229/ https://review.openstack.org/#/c/155620/ The idea with these guidelines is to come up with a set of recommendations to be used going

Re: [openstack-dev] [tooz] 1.0 goals

Julien Danjou wrote: On Mon, Mar 09 2015, Joshua Harlow wrote: Another idea; provide some way for tooz to handle the heartbeating (instead of clients having to do this); perhaps tooz coordinator should take ownership of the thread that heartbeats (instead of clients having to do this on there o

Re: [openstack-dev] [TripleO] Getting to a 1.0

On 03/07/2015 04:34 AM, Dan Prince wrote: On Tue, 2015-03-03 at 17:30 -0500, James Slagle wrote: Hi, Don't let the subject throw you off :) I wasn't sure how to phrase what I wanted to capture in this mail, and that seemed reasonable enough. I wanted to kick off a discussion about what gaps pe

Re: [openstack-dev] [Ironic] Thinking about our python client UX

Hi Devananda, Thanks for bringing this up. I've seen some recent discussions about changing our python-client so that it supports a range of versions of the server. I think that makes sense and that's how/where we can fix the client so that it supports requests/responses that are particular to a v

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On Monday, March 9, 2015, Mike Bayer wrote: > > > Wei D > wrote: > > > +1, > > > > > > > > I am fan of checking the constraints in the controller level instead of > relying on FK constraints itself, thanks. > > Why shouldn’t the storage backends, be they relational or not, be tasked > with verify

Re: [openstack-dev] [tooz] 1.0 goals

So another idea. I know kazoo has/had the following: https://github.com/python-zk/kazoo/pull/141 "Add shared locks and revocable shared lock support" It might be nice if tooz had support for that (the kazoo PR was rejected since there just wasn't enough maintainers in the kazoo project to su

Re: [openstack-dev] [horizon] Kilo angular virtual sprint

Hi everyone, The virtual sprint[1] has been going really well. Last Thursday in the virtual sprint we got 3 patches reviewed and merged! (156810, 157128, 160093) We also had good discussion on the transfer tables and and spinner. With the transfer tables, we decided to make them a parent depen

[openstack-dev] [api][neutron] Re: Best API for generating subnets from pool

Sorry, pulling this from the archives [1] because I seem to have lost the original in my mailbox... > 1) (this is more for neutron people) Is there a real use case for > requesting specific gateway IPs and allocation pools when allocating from a > pool? If not, maybe we should let the pool set a

[openstack-dev] [Ironic] Weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 09 Mar 17:00 UTC) Open: 133 (+4) 3 new (0), 32 in progress (0), 0 critical, 18 high and 8 incomplete Drivers == IPA (jrol

Re: [openstack-dev] [Fuel] Recent issues with our review workflow

+1 on both points, Ryan. On 03/09/2015 01:21 PM, Ryan Moe wrote: Hi All, I've noticed a few times recently where reviews have been abandoned by people who were not the original authors. These reviews were only days old and there was no prior notice or discussion. This is both rude and discourag

Re: [openstack-dev] [horizon] bower

Richard, thanks for sharing this. I hope we can move to bower sooner rather than later. On Sat, Mar 7, 2015 at 5:26 PM, Richard Jones wrote: > On Sun, 8 Mar 2015 at 04:59 Michael Krotscheck > wrote: > >> Anyone wanna hack on a bower mirror puppet module with me? >> > > BTW are you aware of this

Re: [openstack-dev] [swift] auth migration and user data migration

John, thanks for the reply. See questions inline. thanks, Weidong On Mon, Mar 9, 2015 at 8:23 AM John Dickinson wrote: > > > On Mar 9, 2015, at 9:46 AM, Weidong Shao wrote: > > > > hi, > > > > I have a standalone swift cluster with swauth as the auth module. By > standalone, I mean the cluste

Re: [openstack-dev] [tooz] 1.0 goals

On 09/03/15 13:56, Julien Danjou wrote: > Hi fellow developers, > > It'd be nice to achieve a 1.0 release for tooz, as some projects are > already using it, and more are going to adopt it. > > I think we should collect features and potential bugs/limitations we'd > like to have and fix before tha

Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

David, FYI, the last time I chatted with John Dickinson I learned there are numerous API elements not documented. Not meant to be private but the docs have not kept up. How should we handle that? Thanks, Matt Farina On Sat, Mar 7, 2015 at 5:25 PM, David Lyle wrote: > I agree that Horizon shou

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Morgan Fainberg wrote: > > > On Monday, March 9, 2015, Mike Bayer wrote: > > > Wei D wrote: > > > +1, > > > > > > > > I am fan of checking the constraints in the controller level instead of > > relying on FK constraints itself, thanks. > > Why shouldn’t the storage backends, be they re

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 03/08/2015 08:10 AM, Alex Xu wrote: Thanks for Jay point this out! If we have agreement on this and document it, that will be great for guiding developer how to add new API. I know we didn't want extension for API. But I think we still need modularity. I don't think we should put everything i

Re: [openstack-dev] [neutron][vpnaas] VPNaaS Subteam meetings

I guess I'll vote for (D), so that there is the possibility of early (1400 UTC) and late (2100) on alternating weeks, given we don't have much to discuss lately and then changing to (C), if things pick up. Let's discuss at Tuesday's meeting (note DST change for US folks), at 1500 UTC. PCM (Paul

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 03/09/2015 07:32 AM, Christopher Yeoh wrote: So the first thing I think we want to distinguish between plugins being a REST API user or operator concept and it being a tool developers use as a framework to support the Nova REST API. As I've mentioned before I've no problem with the feature se

Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina wrote: > David, > > FYI, the last time I chatted with John Dickinson I learned there are > numerous API elements not documented. Not meant to be private but the docs > have not kept up. How should we handle that? > > I've read through this thread and

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 03/09/2015 03:37 PM, Jay Pipes wrote: > On 03/08/2015 08:10 AM, Alex Xu wrote: >> Thanks for Jay point this out! If we have agreement on this and document >> it, that will be great for guiding developer how to add new API. >> >> I know we didn't want extension for API. But I think we still >> ne

Re: [openstack-dev] [all] oslo.log 1.0.0 release

On Mon, Mar 9, 2015, at 09:21 AM, Doug Hellmann wrote: > The Oslo team is excited to announce the release of: > > oslo.log 1.0.0: oslo.log library > > For more details, please see the git log history below and: > > http://launchpad.net/oslo.log/+milestone/1.0.0 > > Please report issues th

Re: [openstack-dev] [all] oslo.config 1.9.1 release

On Mon, Mar 9, 2015, at 09:09 AM, Doug Hellmann wrote: > The Oslo team is glad to announce the release of: > > oslo.config 1.9.1: Oslo Configuration API > > For more details, please see the git log history below and: > > http://launchpad.net/oslo.config/+milestone/1.9.1 > > Please report

[openstack-dev] [TripleO][Tuskar] Common library for shared code

Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from "more that a single API call to an openstack service", to g

Re: [openstack-dev] [heat][qa] Forward plan for heat scenario tests

On 10/03/15 03:23, Matthew Treinish wrote: On Mon, Mar 09, 2015 at 09:52:54AM -0400, David Kranz wrote: Since test_server_cfn_init was recently moved from tempest to the heat functional tests, there are no subclasses of OrchestrationScenarioTest. If there is no plan to add any more heat scenario

[openstack-dev] new failures running Barbican functional tests

We are getting issues running barbican functional tests - seems to have started sometime between Thursday last week (3/5) and today (3/9) Seems that oslo config giving us DuplicateOptErrors now. Our functional tests use oslo config (via tempest) as well as barbican server code. Looking into

Re: [openstack-dev] [Neutron] Question about bug 1314614

Hello, Answears below Dnia niedziela, 8 marca 2015 13:53:51 Ian Wells pisze: > On 6 March 2015 at 13:16, Sławek Kapłoński wrote: > > Hello, > > > > Today I found bug https://bugs.launchpad.net/neutron/+bug/1314614 because > > I > > have such problem on my infra. > > (For reference, if you dele

Re: [openstack-dev] [heat][qa] Forward plan for heat scenario tests

On Mon, Mar 09, 2015 at 09:52:54AM -0400, David Kranz wrote: > Since test_server_cfn_init was recently moved from tempest to the heat > functional tests, there are no subclasses of OrchestrationScenarioTest. > If there is no plan to add any more heat scenario tests to tempest I would > like to remo

[openstack-dev] [Ironic] proposing rameshg87 to ironic-core

Hi all, I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core. He's been consistently providing good code reviews, and been in the top five active reviewers for the last 90 days and top 10 for the last 180 days. Two cores have recently approached me to let me know that they, too, fin

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Mar 9, 2015, at 13:14, Sean Dague wrote: > So possibly another way to think about this is our prior signaling of > what was supported by Nova was signaled by the extension list. Our code > was refactored into a way that supported optional loading by that unit. > > As we're making things less

[openstack-dev] [Magnum][Heat] Expression of Bay Status

Magnum Team, In the following review, we have the start of a discussion about how to tackle bay status: https://review.openstack.org/159546 I think a key issue here is that we are not subscribing to an event feed from Heat to tell us about each state transition, so we have a low degree of con

Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

I am not core reviewer on all the projects in question, but I’m +1 to this addition. Thanks Ramakrishnan for all the good reviews. -Jay On Mar 9, 2015, at 3:03 PM, Devananda van der Veen mailto:[email protected]>> wrote: Hi all, I'd like to propose adding Ramakrishnan (rameshg87) to iro

Re: [openstack-dev] [horizon] bower

Turns out that the bower registry doesn't actually support https. Git does - so we can prove authenticity of the code - but the address lookup that tells us which git url to pull from? Not so much. I'm still digging, but unless we can get that fixed upstream (or can get everyone to be ok with not

Re: [openstack-dev] [Glance] Core nominations.

Thank you all! The nominations and the consolidation has been implemented. Cheers -Nikhil From: Nikhil Komawar Sent: Sunday, March 8, 2015 2:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Cor

  1   2   >