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

Thanks to everybody working on this, Answers inline: On Tuesday, 10 de March de 2015 at 0:34, Tidwell, Ryan wrote: > Thanks Salvatore. Here are my thoughts, hopefully there’s some merit to them: > > With implicit allocations, the thinking is that this is where a subnet is > created in a b

Re: [openstack-dev] [cinder] Volume Replication and Migration bug triage ...

Hi all, https://bugs.launchpad.net/cinder/+bug/1255622 For this bug, I have added some comments to explain why the "orphaned volume" that ends up in the end of the migration. @John Griffith, I hope this can resolve your confusion a bit. Best wishes, Vincent Hou (侯胜博) Staff Software Engineer, Op

[openstack-dev] [Cinder] Cinder-GlusterFS CI update

Hi All, Quick update. We added GlusterFS CI job (gate-tempest-dsvm-full-glusterfs) to *check pipeline (non-voting)* after the patch @ [1] was merged. Its been running successfully ( so far so good ) on Cinder patches, few examples are in [2] I also updated the 3rd party CI status page [3]

[openstack-dev] [Horizon] Rethinking the launch-instance wizard model

Hi folks, Currently the launch instance model file does all the fetching of various bits of data. Combined with all of the controllers also being loaded at wizard startup, this results in some very difficult synchronisation issues*. An issue I've run into is the initialisation of the controller b

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

Hi Adrian. Anyway, I think `Taskflow` is useful to manage jobs which take a long time. So if we don’t use taskflow to manage bay status, we should use this to manage k8s resources. -- OTSUKA, Motohiro Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Tuesday, March 10, 2015 at 07:53,

Re: [openstack-dev] [Congress]How to add tempest tests for testing murano drive

Hi Hong, I you should be able to run the tempest tests with ./run_tempest.sh -N which by default uses site-packages so they should be installed by the devstack script. If you want to run tempest via tox and venv you'll need to do: echo python-congressclient >> requirements.txt echo python-muranoc

[openstack-dev] [gantt] Scheduler sub-group meeting agenda 3/10

(Note that most of the US has foolishly changed to Daylight Saving Time, check your local time conversion, the meeting is still at 1500 UTC) Meeting on #openstack-meeting at 1500 UTC (9:00AM MDT) 1) Discuss `model request' ( https://blueprints.launchpad.net/nova/+spec/request-spec-objec

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

On Tue, Mar 10, 2015 at 8:53 AM, Adrian Otto wrote: > 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 t

[openstack-dev] [Congress]How to add tempest tests for testing murano drive

Hi Tim and Aaron, I got the latest changes from r157166 and I see the thirdparty-requirements.txt file where you can define the murano client (it's already there), so the unit tests for murano driver can run out from the box. However, this change is only in congress, so the tempest tests (temp

[openstack-dev] oslo.config 1.9.2 release

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

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

On 03/09/2015 01:26 PM, Mike Bayer wrote: Im about -1000 on disabling foreign key constraints. So was I. We didn't do it out of performance. Since I am responsible for tipping over this particular cow, let me explain. No, is too much. Let me sum up. In the murky past, Keystone was primarily

Re: [openstack-dev] new failures running Barbican functional tests

On Mon, Mar 9, 2015, at 05:39 PM, Steve Heyman wrote: > 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

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

Excerpts from Mike Bayer's message of 2015-03-09 17:26:36 -0700: > > Clint Byrum wrote: > > > > > So I think I didn't speak clearly enough here. The benchmarks are of > > course needed, but there's a tipping point when write activity gets to > > a certain level where it's cheaper to let it get

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

+1 for sure! On 9 March 2015 at 18:03, Devananda van der Veen wrote: > 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

[openstack-dev] [Manila] FYI : Micro-versioning for Nova API

Hello Manila, I noticed there were some discussions about api extensions in the past few weeks. Looks like nova has similar discussions too. "Each extension gets a version", if my understanding about the api extension discussion purpose is correct. Not sure if you already known it or not. I'm

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

Clint Byrum wrote: > > So I think I didn't speak clearly enough here. The benchmarks are of > course needed, but there's a tipping point when write activity gets to > a certain level where it's cheaper to let it get a little skewed and > correct asynchronously. This is not unique to SQL, this

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

Ramakrishnan has clearly been reviewing tons of code lately, and more importantly the quality of the reviews and the knowledge of the code base, the problem space, and the edge cases has shown through as nothing short of awesome. Enthusiastic +2 from me! // jim On Mon, 2015-03-09 at 22:03 +,

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

2015-03-09 20:36 GMT+09:00 Christopher Yeoh : > > > 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, versio

Re: [openstack-dev] [all][testing][ci] Local variables in tracebacks

And I forgot my references. Doh. On 10 March 2015 at 12:57, Robert Collins wrote: > I've just finished[1] an arc of development adding showing frame local > variables in tracebacks to our testing stack[2]. Its off by default > since its new and doesn't have the depth of polish that e.g. the > py.

[openstack-dev] [all][testing][ci] Local variables in tracebacks

I've just finished[1] an arc of development adding showing frame local variables in tracebacks to our testing stack[2]. Its off by default since its new and doesn't have the depth of polish that e.g. the py.test equivalent does. Turning it on is easy - bump the subunit library version to get the n

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

Hi, 2015-03-09 20:38 GMT+09:00 John Garbutt : > 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 ca

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

Thanks Salvatore. Here are my thoughts, hopefully there’s some merit to them: With implicit allocations, the thinking is that this is where a subnet is created in a backward-compatible way with no subnetpool_id and the subnets API’s continue to work as they always have. In the case of a specif

Re: [openstack-dev] [horizon] bower

I was wrong. Ignore me on the https thing. On Mon, Mar 9, 2015 at 4:05 PM Michael Krotscheck wrote: > 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 s

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

Excerpts from Mike Bayer's message of 2015-03-09 10:26:37 -0700: > > 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 u

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

+1 for rameshg87! On Mon, Mar 9, 2015 at 10:03 PM, Devananda van der Veen wrote: > 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 fo

[openstack-dev] [Ironic] documenting our core review team policies

As the title says, I've gone ahead and written up our core review team policies, and posted it here: https://wiki.openstack.org/wiki/Ironic/CoreTeam Why now, you may ask? In the interests of full disclosure, we (the current ironic-core team) had a private discussion recently about adding a new m

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

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] [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:devananda@gmail.com>> wrote: Hi all, I'd like to propose adding Ramakrishnan (rameshg87) to iro

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

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

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

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

[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

[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

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

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

[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

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

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

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

[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

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

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

[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

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

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

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

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

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

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

[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

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] stevedore 1.3.0 release

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

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

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

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

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 >

  1   2   >