[openstack-dev] [Ceilometer][Nova][libvirt] Intergration with oVirt-guest-agent

Hi guys! Recently, I have done a simple intergration of Ceilometer, Nova and oVirt-guest-agent(http://www.ovirt.org/Guest_Agent‍). Therefore, by installing ovirt-guest-agent in Windows or Linux, we could get more information such as unused memory size, swap memory size and last login time thr

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

> From: Zane Bitter > To: openstack Development Mailing List > Date: 29/01/2015 17:47 > Subject: [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 t

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

Angus Lees wrote: > > If we absolutely can't switch to another mysql driver, another option that > was suggested recently (and passes the above test) is using > eventlet.monkey_patch(MySQLdb=True). I haven't done the investigation to > find out why that isn't the default, or what the downs

Re: [openstack-dev] [Magnum] Proposed Changes to Magnum Core

+1 Welcome!! OTSUKA, Yuanying -- OTSUKA, Motohiro Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Thursday, January 29, 2015 at 08:40, Jay Lau wrote: > +1! > > Thanks! > > 2015-01-29 6:40 GMT+08:00 Steven Dake (mailto:sd...@redhat.com)>: > > On 01/28/2015 03:27 PM, Adrian Otto w

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

On 01/29/2015 05:28 PM, Kevin Benton wrote: >>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 netw

Re: [openstack-dev] [all] Question about import module

The requirements files are being updated so this fallback is unnecessary. Newer versions of the library (which should be the new minimum version) will work with the first import without issue. The only reason you would do this is if you’re not following global-requirements.txt and have a very low m

Re: [openstack-dev] [all] Question about import module

Suppose that's the way to do it. On Fri, Jan 30, 2015, 7:44 AM liuxinguo wrote: > · I have seen that the module ‘oslo.config’ have changed to > ‘oslo_config’ in Kilo but in Juno it is still ‘oslo.config’. > > > > I want my code work compatibly both for Juno and Kilo so I import this >

[openstack-dev] [all] Question about import module

* I have seen that the module 'oslo.config' have changed to 'oslo_config' in Kilo but in Juno it is still 'oslo.config'. I want my code work compatibly both for Juno and Kilo so I import this module in this way: try: from oslo_config import cfg except: from oslo.config import cfg *

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

> -Original Message- > From: Roman Podoliaka [mailto:rpodoly...@mirantis.com] > Sent: Friday, January 30, 2015 2:12 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [api][nova] Openstack HTTP error codes > > Hi Anne, > > I think Eugeniya

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

On Thu, Jan 29, 2015 at 5:15 PM, Michael Still wrote: > There is an ec2 bug tag in launchpad. I would link to it except I am writing > this offline. I will fix that later today. Ok, now that the 40 seater turbo prop has landed, here we go: https://bugs.launchpad.net/nova/+bugs?field.tag=ec2 > H

Re: [openstack-dev] [all][log] Openstack HTTP error codes

Hi folks! Changed the tags a bit because this is a discussion for all projects and dovetails with logging rationalization/standards/ At the Paris summit, we had a number of session on logging that kept circling back to Error Codes. But, these codes would not be http codes, rather, as others h

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

On Thu, Jan 29, 2015, Morgan Fainberg wrote: > The concept that there is a utility that can (and in many cases > willfully) cause permanent, and in some cases irrevocable, data loss > from a simple command line interface sounds crazy when I try and > explain it to someone. > > The more I work wit

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

There is an ec2 bug tag in launchpad. I would link to it except I am writing this offline. I will fix that later today. However I think what we've shown is that moving this code out of nova is the future. I would like to see someone come up with a plan to transition users to the stackforge project

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

Michael, Seems like Wataru from CERN is working on testing EC2. He is adding Rally scenarios related to EC2: https://review.openstack.org/#/c/147550/ So at least EC2 will have good functional/perf test coverage. Best regards, Boris Pavlovic On Fri, Jan 30, 2015 at 3:11 AM, matt wrote: > Is th

Re: [openstack-dev] [OpenStack Foundation] Finding people to work on the EC2 API in Nova

Is there a blue print or some set of bugs tagged in some way to tackle? -matt On Thu, Jan 29, 2015 at 7:01 PM, Michael Still wrote: > Hi, > > as you might have read on openstack-dev, the Nova EC2 API > implementation is in a pretty sad state. I wont repeat all of those > details here -- you can

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

The other factor I haven't seen mentioned here is that our usual eventlet+mysqldb setup can deadlock rather easily(*), resulting in the entire python process sitting idle for 30s until the mysqldb deadlock timer goes off and raises an exception. At this point (in nova at least), the request is usu

[openstack-dev] Finding people to work on the EC2 API in Nova

Hi, as you might have read on openstack-dev, the Nova EC2 API implementation is in a pretty sad state. I wont repeat all of those details here -- you can read the thread on openstack-dev for detail. However, we got here because no one is maintaining the code in Nova for the EC2 API. This is despi

[openstack-dev] Gerrit downtime Friday Jan 30

Hi, On Friday, January 30 at 19:00 UTC Gerrit will be unavailable for about 30 minutes while we rename some projects. Existing reviews, project watches, etc, should all be carried over. Currently, we plan on renaming the following projects (this list is subject to change): openstack/oslo.ve

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

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

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

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

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

[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

[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

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]

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

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

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

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

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

[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

[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

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

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

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

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

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

  1   2   >