Re: [openstack-dev] [nova] Nominating Melanie Witt for python-novaclient-core

On 01/27/2015 11:41 PM, Michael Still wrote: > Greetings, > > I would like to nominate Melanie Witt for the python-novaclient-core team. > > (What is python-novaclient-core? Its a new group which will contain > all of nova-core as well as anyone else we think should have core > reviewer powers on

Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)

> -Original Message- > From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] > Sent: 28 January 2015 21:29 > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only > Affects Project/Tenant/Role/Assignmen

[openstack-dev] CLI support in ML2 driver

Hi, I have more expertise in Opendaylight than Openstack.I have created a CLI application in Opendaylight which uses AdventNetCLI library in SB that will create/delete services in my non-openflow carrier ethernet switch through RESTCONF(It's working!). I want this app to be called from the Neut

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

Guys, could you point out where I suggested to use python for testing puppet manifests? On Thu, Jan 29, 2015 at 1:28 AM, Sergii Golovatiuk wrote: > We need to write tests in way how Puppet community writes. Though if user > uses salt in one stage, it's fine to use tests on python. > > -- > Best

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Dmitry, Evgeniy This is exactly what I was talking about when I mentioned serializers for tasks - taking data from 3rd party sources if user wants. In this case user will be able to generate some data somewhere and fetch it using this code that we import. On Thu, Jan 29, 2015 at 12:08 AM, Dmitriy

[openstack-dev] [Fuel] Plugins repositories moved to stackforge

Hi, guys All our plugins repositories are moved to stackforge. Each plugin has separate repo and now can be maintained independently from core product cycle and without core-team attraction. Here is a map of migration: https://github.com/stackforge/fuel-plugins/tree/master/external_glusterfs ->

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

>Why would users want to change an active port's IP address anyway? Re-addressing. It's not common, but the entire reason I brought this up is because a user was moving an instance to another subnet on the same network and stranded one of their VMs. > I worry about setting a default config value

Re: [openstack-dev] [Fuel] Plugins repositories moved to stackforge

Do we have a plan to enable CI for this repositories? Tests to run on commits, nightly builds, integration with nightly system tests? Should it be part of Fuel CI or completely independent? On Thu, Jan 29, 2015 at 11:55 AM, Alexander Kislitsky wrote: > Hi, guys > > All our plugins repositories

Re: [openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

Guys I would just like to point out that we will certainly need to consume resources from 3rd party sources also. We also want to remove any specific data manipulation from puppet code. Please, consider these use cases also. On Thu, Jan 29, 2015 at 12:06 AM, Dmitriy Shulyak wrote: > > 1. as I m

Re: [openstack-dev] [Swift] Swift GUI (free or open source)?

On Wed, 2015-01-28 at 17:35 -0800, Adam Lawson wrote: > Okay cool beans. Incidentally, are there any efforts out there going > through the motions that you know about (even abandoned)? I'd be willing to > prop them a bit if they're low on development resources.. I don't know of any such project(s)

Re: [openstack-dev] [Fuel] Plugins repositories moved to stackforge

CI is requirement only for certified plugins. Is CI part of Fuel CI or not depends only on the plugin. In some cases we just can't run plugin CI on Fuel CI environment. On Thu, Jan 29, 2015 at 1:03 PM, Aleksandra Fedorova wrote: > Do we have a plan to enable CI for this repositories? Tests to r

Re: [openstack-dev] [Openstack][dev][Zuul] Merge Failed Error in CI - GitPython Error

yes, thanks for the posting the patch ramy. On Tue, Jan 27, 2015 at 9:02 PM, Asselin, Ramy wrote: > Punith, > > > > I think it’s because when you installed fresh again on 14.04, the zuul > GitPython dependency was updated to the latest. > > > > I proposed this zuul patch to fix it: > https://re

Re: [openstack-dev] [api] Next meeting agenda

Everett Toews wrote: > A couple of important topics came up as a result of attending the > Cross Project Meeting. I’ve added both to the agenda for the next > meeting on Thursday 2015/01/29 at 16:00 UTC. > > https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda > > The first is the suggestion fr

Re: [openstack-dev] [all][oslo] oslo namespace package releases are done

On 01/29/2015 01:00 AM, Doug Hellmann wrote: You will all, I am sure, be relieved to know that the oslo.vmware release today was the last library that needed to be released with namespace package changes. There are a few more patches to land to the requirements list to update the minimum requi

Re: [openstack-dev] [nova] The libvirt.cpu_mode and libvirt.cpu_model

On Wed, Jan 28, 2015 at 10:10:29PM +, Jiang, Yunhong wrote: > Hi, Daniel > I recently tried the libvirt.cpu_mode and libvirt.cpu_model > when I was working on cpu_info related code and found bug > https://bugs.launchpad.net/nova/+bug/1412994 . The reason is because > with these two flags

Re: [openstack-dev] [Fuel] removing single mode

Mike, > Any objections / additional suggestions? no objections from me, and it's already covered by LP 1415116 bug [1] [1] https://bugs.launchpad.net/fuel/+bug/1415116 On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov wrote: > Folks, > one of the things we should not forget about - is out Fuel

Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch

Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

I hope, we don’t even consider using python for that. Let’s be as close as possible to community and use rspec for manifests. Regards, > On 29 Jan 2015, at 09:50, Vladimir Kuklin wrote: > > Guys, could you point out where I suggested to use python for testing puppet > manifests? > > On Thu,

Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)

Hello. On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg wrote: > LDAP is used in Keystone as a backend for both the Identity (Users and > groups) and assignments (assigning roles to users) backend. > > Where did the LDAP Assignment backend come from? We originally had a > single backend for Ide

Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles

Hi, Ok, looks like everybody agree that we should implement similar approach for plugins. But I'm not sure if we should implicitly assume that primary is set if there is only 'controller', in this case we won't be able to run some tasks on controllers only. Thanks, On Thu, Jan 29, 2015 at 1:05 A

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Vladimir, It's no clear how it's going to help. You can generate keys with one tasks and then upload them with another task, why do we need another layer/entity here? Thanks, On Thu, Jan 29, 2015 at 11:54 AM, Vladimir Kuklin wrote: > Dmitry, Evgeniy > > This is exactly what I was talking about

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

Guys, We have requests for this improvement. It will help with huge environments, we are talking about >5GiB of logs. Is it on the agenda? Regards, > On 22 Dec 2014, at 07:28, Bartlomiej Piotrowski > wrote: > > FYI, xz with multithreading support (5.2 release) has been marked as stable > y

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Evgeniy This is not about layers - it is about how we get data. And we need to separate data sources from the way we manipulate it. Thus, sources may be: 1) Nailgun DB 2) Users inventory system 3) Opendata like, list of Google DNS Servers. Then all this data is aggregated and transformed somehow.

Re: [openstack-dev] [Fuel] [Puppet] Manifests for granular deploy steps and testing results against the host OS

Guys I just suggested to use serverspec as beaker is a kind of overkill duplicating our fuel-devops framework, so that we do not need to mess with beaker ways of environment creation. On Thu, Jan 29, 2015 at 2:08 PM, Tomasz Napierala wrote: > I hope, we don’t even consider using python for that.

Re: [openstack-dev] Deprecation of in tree EC2 API in Nova for Kilo release

Thomas, I'm the lead of the team working on it. The project is in a release-candidate state and the EC2 (non-VPC) part is just being finished, so there are no tags or branches yet. Also we were not sure about what should we do with it since we were told that it'll have a chance of going as a p

[openstack-dev] Weekly status report (Thu, Jan 22)

Hello, a bit early, but here's my status report for the past week RED: - none AMBER: - still preparing my workshop for devconf in Brno - prepared a patch to add OVA format to horizon https://review.openstack.org/150751 - continued JavaScript fun - cleaned up blueprints upstream - bugzilla housek

Re: [openstack-dev] Weekly status report (Thu, Jan 22)

On 29/01/15 13:20, Matthias Runge wrote: > Hello, > > a bit early, but here's my status report for the past week Yupp, please ignore the noise here. Matthias __ OpenStack Development Mailing List (not for usage questions) U

Re: [openstack-dev] CLI support in ML2 driver

Hi, you can develop you own service plugin which extends the current Neutron API, and transforms Neutron API call in ODL NB API call. You can take example from the GBP service plugin to understand how to route Neutron API call to an independent service plugin. regards, Mathieu On Thu, Jan 29,

Re: [openstack-dev] [oslo.db] PyMySQL review

On Wed, Jan 28, 2015, at 07:57 PM, Johannes Erdfelt wrote: > On Wed, Jan 28, 2015, Vishvananda Ishaya wrote: > > On Jan 28, 2015, at 4:03 PM, Doug Hellmann wrote: > > > I hope someone who was around at the time will chime in with more detail > > > about why green threads were deemed better than

Re: [openstack-dev] [api] Next meeting agenda

On 1/29/15, 04:10, "Thierry Carrez" wrote: >Everett Toews wrote: >> A couple of important topics came up as a result of attending the >> Cross Project Meeting. I’ve added both to the agenda for the next >> meeting on Thursday 2015/01/29 at 16:00 UTC. >> >> https://wiki.openstack.org/wiki/Meeti

Re: [openstack-dev] [api] Next meeting agenda

On Thu, Jan 29, 2015 at 4:10 AM, Thierry Carrez wrote: > Everett Toews wrote: > > A couple of important topics came up as a result of attending the > > Cross Project Meeting. I’ve added both to the agenda for the next > > meeting on Thursday 2015/01/29 at 16:00 UTC. > > > > https://wiki.openstack

Re: [openstack-dev] [api] Next meeting agenda

On 01/29/2015 07:17 AM, Anne Gentle wrote: > > > On Thu, Jan 29, 2015 at 4:10 AM, Thierry Carrez > wrote: > > Everett Toews wrote: > > A couple of important topics came up as a result of attending the > > Cross Project Meeting. I’ve added both to the ag

Re: [openstack-dev] [api] Next meeting agenda

On 01/29/2015 10:20 AM, Sean Dague wrote: > On 01/29/2015 07:17 AM, Anne Gentle wrote: >> >> >> On Thu, Jan 29, 2015 at 4:10 AM, Thierry Carrez > > wrote: >> >> Everett Toews wrote: >> > A couple of important topics came up as a result of attending the >> >

Re: [openstack-dev] problems with instance consoles and novnc

Is SSL involved anywhere from the client browser to the server ? Is there any load balancing ? Which load balancer software ? -- David Moreau Simard On 2015-01-28, 11:57 PM, "Chris Friesen" wrote: >On 01/28/2015 10:33 PM, Mathieu Gagné wrote: >> On 2015-01-28 11:13 PM, Chris Friesen wrote: >>>

Re: [openstack-dev] [oslo.db] PyMySQL review

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/2015 06:57 PM, Johannes Erdfelt wrote: > Not sure if it helps more than this explanation, but there was a > blueprint and accompanying wiki page that explains the move from twisted > to eventlet: Yeah, it was never threads vs. greenthreads.

Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

On 01/24/2015 02:01 AM, Doug Hellmann wrote: > > > On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote: >> Hi, >> >> I've just noticed that oslo.log made it to global-requirements.txt 9 >> days ago. How come are we still adding some name.spaced oslo libs? >> Wasn't the outcome of the discussi

Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

On Thu, Jan 29, 2015, at 11:03 AM, Thomas Goirand wrote: > On 01/24/2015 02:01 AM, Doug Hellmann wrote: > > > > > > On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote: > >> Hi, > >> > >> I've just noticed that oslo.log made it to global-requirements.txt 9 > >> days ago. How come are we sti

[openstack-dev] [api][nova] Openstack HTTP error codes

Hi, all Openstack APIs interact with each other and external systems partially by passing of HTTP errors. The only valuable difference between types of exceptions is HTTP-codes, but current codes are generalized, so external system can’t distinguish what actually happened. As an example two diff

[openstack-dev] oslo.middleware 0.4.0 released

The Oslo team is pleased to announce the release of: oslo.middleware 0.4.0: Oslo Middleware library This release adds a new middleware class for adding a health-check endpoint to a REST service. For more details, please see the git log history below and: http://launchpad.net/oslo.middleware/+mi

Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

On Thu, Jan 29 2015, Thomas Goirand wrote: Hi Thomas, > The Debian policy is that Python module packages should be named after > the import statement in a source file. Meaning that if we do: > > import oslo_db > > then the package should be called python-oslo-db. > > This means that I will have

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

On Thu, Jan 29, 2015 at 2:55 AM, Kevin Benton wrote: > >Why would users want to change an active port's IP address anyway? > > Re-addressing. It's not common, but the entire reason I brought this up is > because a user was moving an instance to another subnet on the same network > and stranded on

[openstack-dev] [Heat][Keystone] Native keystone resources in Heat

I got a question today about creating keystone users/roles/tenants in Heat templates. We currently support creating users via the AWS::IAM::User resource, but we don't have a native equivalent. IIUC keystone now allows you to add users to a domain that is otherwise backed by a read-only backen

Re: [openstack-dev] [oslo.db] PyMySQL review

On 2015-01-29 18:35:20 +0200 (+0200), Roman Podoliaka wrote: [...] > Otherwise, PyMySQL would be much slower than MySQL-Python for the > typical SQL queries we do (e.g. ask for *a lot* of data from the DB). [...] Is this assertion based on representative empirical testing (for example profiling de

Re: [openstack-dev] [oslo.db] PyMySQL review

Hi all, Mike, thanks for summarizing this in https://wiki.openstack.org/wiki/PyMySQL_evaluation ! On PyMySQL: this is something we need to enable testing of oslo.db on Python 3.x and PyPy. Though, I doubt we want to make PyMySQL the default DB API driver for OpenStack services for Python 2.x. At

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

On Thu, Jan 29, 2015 at 10:33 AM, Eugeniya Kudryashova < ekudryash...@mirantis.com> wrote: > Hi, all > > > Openstack APIs interact with each other and external systems partially by > passing of HTTP errors. The only valuable difference between types of > exceptions is HTTP-codes, but current codes

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

Sean Dague wrote: > On 01/27/2015 05:21 PM, Sean Dague wrote: >> On 01/27/2015 03:55 PM, Douglas Mendizabal wrote: >>> Hi openstack-dev, >>> >>> The barbican team would like to announce the release of >>> python-barbicanclient 3.0.2. This is a minor release that fixes a bug >>> in the pbr versioni

Re: [openstack-dev] [oslo.db] PyMySQL review

Roman Podoliaka wrote: > > On native threads vs green threads: I very much like the Keystone > approach, which allows to run the service using either eventlet or > Apache. It would be great, if we could do that for other services as > well. but why do we need two approaches to be at all expli

Re: [openstack-dev] [oslo.db] PyMySQL review

Jeremy, I don't have exact numbers, so yeah, it's just an assumption based on looking at the nova-api/scheduler logs with connection_debug set to 100. But that's a good point you are making here: it will be interesting to see what difference enabling of PyMySQL will make for tempest/rally workloa

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

Good question! I was planning a keystone liens release very soon, but will hold off of it will break everything. --Morgan On Thursday, January 29, 2015, Thierry Carrez wrote: > Sean Dague wrote: > > On 01/27/2015 05:21 PM, Sean Dague wrote: > >> On 01/27/2015 03:55 PM, Douglas Mendizabal wrote:

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: > I got a question today about creating keystone users/roles/tenants in Heat > templates. We currently support creating users via the AWS::IAM::User > resource, but we don't have a native equivalent. Note that AWS::IAM::User actually cre

Re: [openstack-dev] [oslo.db] PyMySQL review

On Thursday, January 29, 2015, Roman Podoliaka wrote: > Hi all, > > Mike, thanks for summarizing this in > https://wiki.openstack.org/wiki/PyMySQL_evaluation ! > > On PyMySQL: this is something we need to enable testing of oslo.db on > Python 3.x and PyPy. Though, I doubt we want to make PyMySQL

Re: [openstack-dev] [oslo.db] PyMySQL review

Mike, I can't agree more: as far as we are concerned, every service is yet another WSGI app. And it should be left up to operator, how to deploy it. So 'green thread awareness' (i.e. patching of the world) should go to separate keystone|*-eventlet binary, while everyone else will still be able to

Re: [openstack-dev] [tc] Take back the naming process

On 01/28/2015 07:24 PM, Adam Lawson wrote: > I'm short on time so I apologize for my candor since I need to get straight > to the point. > > I love reading the various opinions and my team is immensely excited with > OpenStack is maturing. But this is lunacy. > > I looked at the patch being worke

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

Maybe we should defer all client releases until we know for sure if each of them are ticking timebombs. On Thu, Jan 29, 2015 at 11:00 AM, Morgan Fainberg wrote: > Good question! I was planning a keystone liens release very soon, but will > hold off of it will break everything. > > --Morgan > > >

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

Hi Anne, I think Eugeniya refers to a problem, that we can't really distinguish between two different badRequest (400) errors (e.g. wrong security group name vs wrong key pair name when starting an instance), unless we parse the error description, which might be error prone. Thanks, Roman On Th

Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

Julien Danjou wrote: > On Thu, Jan 29 2015, Thomas Goirand wrote: > > Hi Thomas, > >> The Debian policy is that Python module packages should be named after >> the import statement in a source file. Meaning that if we do: >> >> import oslo_db >> >> then the package should be called python-oslo-db

Re: [openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

Dmitry, >> But why to add another interface when there is one already (rest api)? I'm ok if we decide to use REST API, but of course there is a problem which we should solve, like versioning, which is much harder to support, than versioning in core-serializers. Also do you have any ideas how it c

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

On 29/01/15 12:03, Steven Hardy wrote: On Thu, Jan 29, 2015 at 11:41:36AM -0500, Zane Bitter wrote: >IIUC keystone now allows you to add users to a domain that is otherwise >backed by a read-only backend (i.e. LDAP). If this means that it's now >possible to configure a cloud so that one need not

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

Correct. This actually came up at the Nova mid cycle in a side conversation with Ironic and Neutron folks. HTTP error codes are not sufficiently granular to describe what happens when a REST service goes wrong, especially if it goes wrong in a way that would let the client do something other than

Re: [openstack-dev] [Heat][Keystone] Native keystone resources in Heat

Excerpts from Zane Bitter's message of 2015-01-29 08:41:36 -0800: > I got a question today about creating keystone users/roles/tenants in > Heat templates. We currently support creating users via the > AWS::IAM::User resource, but we don't have a native equivalent. > > IIUC keystone now allows y

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

So, honestly, yes. For a library to release safely it must: * have stable-compat jobs running (this was the issue with barbican client) * if it has a stable/juno branch it must be pinned in stable/juno (this was the issue on most of the oslo libs) -Sean On 01/29/2015 12:07 PM, Kyle Mest

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

If you're going to make up your own extensions[1] to HTTP, why don't you use ones that are already used? http://support.microsoft.com/kb/943891 [1] ok, what's proposed isn't technically an "extension", it's response body context for the response code. But response bodies are hard to modify wh

Re: [openstack-dev] [tc] Take back the naming process

Hi Anne; this was more or less directed in Monty's direction and/or those in agreement with his position. Sorry for the confusion, I probably should have been a bit more clear. ; ) Mahalo, Adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-fr

Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

Just something to note; anvil has never ran had issues with this (afaik). It seems fairly easy to have a mapping/algorithm/other... that is used imho (and this is just what anvil has); I don't recall that the number of problems with weird names has been any real issue when building rpms... It'

Re: [openstack-dev] [nova] The libvirt.cpu_mode and libvirt.cpu_model

> -Original Message- > From: Daniel P. Berrange [mailto:berra...@redhat.com] > Sent: Thursday, January 29, 2015 2:34 AM > To: Jiang, Yunhong > Cc: openstack-dev@lists.openstack.org > Subject: Re: [nova] The libvirt.cpu_mode and libvirt.cpu_model > > On Wed, Jan 28, 2015 at 10:10:29PM +000

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Vladimir, >> 1) Nailgun DB Just a small note, we should not provide access to the database, this approach has serious issues, what we can do is to provide this information for example via REST API. What you are saying is already implemented in any deployment tool for example lets take a look at

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On 2015-01-29 09:00:42 -0800 (-0800), Morgan Fainberg wrote: > Good question! I was planning a keystone liens release very soon, > but will hold off of it will break everything.  I believe part of the problem is that python-barbicanclient doesn't yet have backward-compatibility jobs running on its

Re: [openstack-dev] [oslo.db] PyMySQL review

On 01/29/2015 05:57 PM, Roman Podoliaka wrote: Jeremy, I don't have exact numbers, so yeah, it's just an assumption based on looking at the nova-api/scheduler logs with connection_debug set to 100. But that's a good point you are making here: it will be interesting to see what difference enabli

Re: [openstack-dev] [oslo.db] PyMySQL review

On Jan 29, 2015, at 8:57 AM, Roman Podoliaka wrote: > Jeremy, > > I don't have exact numbers, so yeah, it's just an assumption based on > looking at the nova-api/scheduler logs with connection_debug set to > 100. > > But that's a good point you are making here: it will be interesting to > see

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague wrote: > So, honestly, yes. > > For a library to release safely it must: > > * have stable-compat jobs running (this was the issue with barbican client) > * if it has a stable/juno branch it must be pinned in stable/juno (this > was the issue on most of

Re: [openstack-dev] [oslo.db] PyMySQL review

Excerpts from Vishvananda Ishaya's message of 2015-01-29 10:21:58 -0800: > > On Jan 29, 2015, at 8:57 AM, Roman Podoliaka wrote: > > > Jeremy, > > > > I don't have exact numbers, so yeah, it's just an assumption based on > > looking at the nova-api/scheduler logs with connection_debug set to >

Re: [openstack-dev] [oslo.db] PyMySQL review

On 2015-01-29 10:21:58 -0800 (-0800), Vishvananda Ishaya wrote: [...] > I don’t think switching is going to give us much benefit right > away. We will need a few optimizations and bugfixes in other areas > (particularly in our sqlalchemy usage) before we will derive any > benefit from the switch.

Re: [openstack-dev] [sahara] team meeting Jan 29 1400 UTC

Log: http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-01-29-14.04.html Minutes: http://eavesdrop.openstack.org/meetings/sahara/2015/sahara.2015-01-29-14.04.log.html On Wed, Jan 28, 2015 at 6:46 PM, Sergey Lukjanov wrote: > Hi folks, > > We'll be having the Sahara team meeting in #

Re: [openstack-dev] [api] API Definition Formats

On 01/28/2015 12:56 PM, Max Lincoln wrote: tl;dr: I wanted to be able to see what OpenStack APIs might look like in Swagger and starting experimenting with Swagger in projects for things like stubbing services, API test coverage, and code generation. In order to do that I created wadl2swagger [1]

[openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

As a quick preface, today there is the assumption you can upgrade and downgrade your SQL Schema. For the most part we do our best to test all of this in our unit tests (do upgrades and downgrades land us in the same schema). What isn’t clearly addressed is that the concept of downgrade might be

[openstack-dev] [Ironic] volunteer to be rep for third-party CI

Hi, Want to contribute even more to the Ironic community? Here's your opportunity! Anita Kuno (anteaya) would like someone to be the Ironic representative for third party CIs. What would you have to do? In her own words: "mostly I need to know who they are so that when someone has questions I can

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote: > On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague wrote: > > > So, honestly, yes. > > > > For a library to release safely it must: > > > > * have stable-compat jobs running (this was the issue with barbican client) > > * if it has a stable/juno b

[openstack-dev] django-openstack-auth and stable/icehouse

Hi All, There was a change [1] 2 days ago in django-openstack-auth that introduces a new requirement oslo.config>=1.6.0 to the project, which is now present in the 1.1.9 release of django-openstack-auth. While this change is in sync with master requirements, oslo.config>=1.6.0, it does not jive

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

On 01/29/2015 11:06 AM, Morgan Fainberg wrote: > As a quick preface, today there is the assumption you can upgrade and > downgrade your SQL Schema. For the most part we do our best to test all of > this in our unit tests (do upgrades and downgrades land us in the same > schema). What isn’t clear

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

I don't understand what you are suggesting here. All of these codes will be for specific openstack service error conditions. The codes in the link you provided don't provide any useful information to callers other than more details about how a web-server is (mis)configured. I didn't see anything re

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

On Thu, Jan 29, 2015 at 11:41 AM, Sean Dague wrote: > Correct. This actually came up at the Nova mid cycle in a side > conversation with Ironic and Neutron folks. > > HTTP error codes are not sufficiently granular to describe what happens > when a REST service goes wrong, especially if it goes wr

Re: [openstack-dev] [tc] Take back the naming process

On 01/29/2015 11:56 AM, Adam Lawson wrote: > Hi Anne; this was more or less directed in Monty's direction and/or those > in agreement with his position. Sorry for the confusion, I probably should > have been a bit more clear. ; ) > > Mahalo, > Adam Okay, thanks Adam. My name is Anita. Thanks, An

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

> On Jan 29, 2015, at 2:27 PM, Monty Taylor wrote: > > On 01/29/2015 11:06 AM, Morgan Fainberg wrote: >> As a quick preface, today there is the assumption you can upgrade and >> downgrade your SQL Schema. For the most part we do our best to test all of >> this in our unit tests (do upgrades an

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

> >> Are downward migrations really a good idea for us to support? Is this > >> downward migration path a sane expectation? In the real world, would any > >> one really trust the data after migrating downwards? are downward migrations actually mandated? i always assumed it was just been a pai

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

I think there are two points. First, the original requirement (in the first email on this thread) is not what's wanted: "...looking at the response body and HTTP response code an external system can’t understand what exactly went wrong. And parsing of error messages here is not the way we’d lik

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

Morgan Fainberg wrote: > > Are downward migrations really a good idea for us to support? Is this > downward migration path a sane expectation? In the real world, would any one > really trust the data after migrating downwards? It’s a good idea for a migration script to include a rudimentary

Re: [openstack-dev] [Ironic] volunteer to be rep for third-party CI

Hi ruby, I'd be interested in this. Let me know next steps when ready? Thanks! On Jan 29, 2015 11:14 AM, "Ruby Loo" wrote: > Hi, > > Want to contribute even more to the Ironic community? Here's your > opportunity! > > Anita Kuno (anteaya) would like someone to be the Ironic representative > for

Re: [openstack-dev] [oslo.db] PyMySQL review

On Thu, Jan 29, 2015 at 11:05 AM, Roman Podoliaka wrote: > Mike, > > I can't agree more: as far as we are concerned, every service is yet > another WSGI app. And it should be left up to operator, how to deploy > it. > > So 'green thread awareness' (i.e. patching of the world) should go to > separ

Re: [openstack-dev] [Ironic] volunteer to be rep for third-party CI

On 01/29/2015 02:32 PM, Adam Lawson wrote: > Hi ruby, I'd be interested in this. Let me know next steps when ready? > > Thanks! Hi Adam: It requires someone who knows the code base really well. While core review permissions are not required, the person fulfilling this role needs to have the confi

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

On 01/29/2015 03:55 AM, Kevin Benton wrote: >>Why would users want to change an active port's IP address anyway? > > Re-addressing. It's not common, but the entire reason I brought this up is > because a user was moving an instance to another subnet on the same network > and > stranded one of the

Re: [openstack-dev] [all][tc] SQL Schema Downgrades and Related Issues

On Thursday 29 January 2015 22:06:25 Morgan Fainberg wrote: > I’d like to propose we stop setting the expectation that a downwards > migration is a “good idea” or even something we should really support. > Offering upwards-only migrations would also simplify the migrations in > general. This downwa

Re: [openstack-dev] design question : green thread model

Hi, nova-conductor starts multiple processes as well. Belmiro On Wednesday, January 28, 2015, Johannes Erdfelt wrote: > On Wed, Jan 28, 2015, murali reddy > > wrote: > > On hosts with multi-core processors, it does not seem optimal to run a > > single service instance with just green thread. I

Re: [openstack-dev] [Fuel] Distribution of keys for environments

Evgeniy, I am not suggesting to go to Nailgun DB directly. There obviously should be some layer between a serializier and DB. On Thu, Jan 29, 2015 at 9:07 PM, Evgeniy L wrote: > Vladimir, > > >> 1) Nailgun DB > > Just a small note, we should not provide access to the database, this > approach >

Re: [openstack-dev] [Fuel] removing single mode

Folks, Changes in CI jobs have been made, for master branch of fuel-library we are running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN . Job naming schema has also been changed, so now it includes actual testgroup. Current links for master branch CI jobs are [1] and [2], all other jobs ca

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

> On Jan 29, 2015, at 1:19 PM, Doug Hellmann wrote: > > > > On Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote: >> On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague wrote: >> >>> So, honestly, yes. >>> >>> For a library to release safely it must: >>> >>> * have stable-compat jobs running (this

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

>How is Neutron breaking this? If I move a port on my physical switch to a different subnet, can you still communicate with the host sitting on it? Probably not since it has a view of the world (next-hop router) that no longer exists, and the network won't route packets for it's old IP address to

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

Oh, I understood it a little differently. I took "parsing of error messages here is not the way we’d like to solve this problem" as meaning that parsing them in their current ad-hoc, project-specific format is not the way we want to solve this (e.g. the way tempest does it). But if we had a structu

Re: [openstack-dev] [barbican] python-barbicanclient 3.0.2 released

On Thu, Jan 29, 2015 at 2:22 PM, Douglas Mendizabal < douglas.mendiza...@rackspace.com> wrote: > > On Jan 29, 2015, at 1:19 PM, Doug Hellmann wrote: > > > > On Thu, Jan 29, 2015, at 01:31 PM, Joe Gordon wrote: > > On Thu, Jan 29, 2015 at 9:52 AM, Sean Dague wrote: > > So, honestly, yes. > > For

Re: [openstack-dev] [api][nova] Openstack HTTP error codes

On Jan 29, 2015, at 2:52 PM, Kevin Benton mailto:blak...@gmail.com>> wrote: Oh, I understood it a little differently. I took "parsing of error messages here is not the way we’d like to solve this problem" as meaning that parsing them in their current ad-hoc, project-specific format is not the

Re: [openstack-dev] [api] Next meeting agenda

Ryan Brown [mailto:rybr...@redhat.com], January 29, 2015 7:29 AM wrote: On 01/29/2015 10:20 AM, Sean Dague wrote: > On 01/29/2015 07:17 AM, Anne Gentle wrote: >> >> >> On Thu, Jan 29, 2015 at 4:10 AM, Thierry Carrez > > wrote: >> >> Everett Toews wrote: >> > A

  1   2   >