Re: [openstack-dev] [nova] volume affinity filter for nova scheduler

On Wed 10 Jul 2013 (13:10), Joe Gordon wrote: > On Mon, Jul 8, 2013 at 8:53 AM, Ilya Kharin wrote: > > > Hi all. > > > > In my opinion it is about things that can live in one form or another, > > because > > in some cases there is a need to place an instance in the same place where > > its > > bl

Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

On Wed, 2013-07-10 at 14:14 -0600, John Griffith wrote: > > Given that Cinder doesn't have anybody actively engaged in this other > than what's being proposed and worked on by Boris and folks, we'd be a > willing candidate for most of these changes, particularly if they're > accepted in N

Re: [openstack-dev] [TripleO] mid-cycle sprint?

Excerpts from Robert Collins's message of 2013-07-10 20:54:26 -0700: > Clint suggested we do a mid-cycle sprint at the weekly meeting a > fortnight ago, but ETIME and stuff - so I'm following up. > > HP would be delighted to host a get-together of TripleO contributors > [or 'I will be contributing

Re: [openstack-dev] [nova] volume affinity filter for nova scheduler

On Thu, Jul 11, 2013 at 9:12 AM, Álvaro López García wrote: > On Wed 10 Jul 2013 (13:10), Joe Gordon wrote: >> On Mon, Jul 8, 2013 at 8:53 AM, Ilya Kharin wrote: >> >> > Hi all. >> > >> > In my opinion it is about things that can live in one form or another, >> > because >> > in some cases there

Re: [openstack-dev] Blueprint: Separate translation domain for log messages

Hi Daisy, On Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote: > Hi, Mark > > I think there is a blueprint we discussed in the Havana summit to > separate translation domains. > https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain > > I don't see any progress there. >

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Wed, 2013-07-10 at 21:14 +0200, Thomas Hervé wrote: > > > On Wed, Jul 10, 2013 at 8:32 PM, Mark McLoughlin > wrote: > On Wed, 2013-07-10 at 11:01 -0700, Nachi Ueno wrote: > > > Personally, I prefer not to use exception for such cases. > > > > The key here i

Re: [openstack-dev] Blueprint: Separate translation domain for log messages

On Thu, Jul 11, 2013 at 9:39 AM, Mark McLoughlin wrote: > Hi Daisy, > > On Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote: > > Hi, Mark > > > > I think there is a blueprint we discussed in the Havana summit to > > separate translation domains. > > > https://blueprints.launchpad.net/oslo/+spe

Re: [openstack-dev] Blueprint: Separate translation domain for log messages

On Thu, 2013-07-11 at 09:56 +0100, Joe Gordon wrote: > > > > On Thu, Jul 11, 2013 at 9:39 AM, Mark McLoughlin wrote: > Hi Daisy, > > On Wed, 2013-07-10 at 21:48 +0800, Ying Chun Guo wrote: > > Hi, Mark > > > > I think there is a blueprint we disc

Re: [openstack-dev] Question -- whu does object data always go to a single swift node?

Snider, Tim wrote: > Here’s a novice question. > > My stack has 2 swift nodes. As expect curl commands addressed to the > controller node to get auth and url information bounce between the 2 > swift nodes as expected. This list is about the future development of OpenStack. You should ask your qu

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Sean Dague wrote: > I think we need to get strict on projects and prevent them from capping > their client requirements. That will also put burden on clients that > they don't break backwards compatibility (which I think was a goal > regardless). Indeed. The whole idea behind a single release chan

Re: [openstack-dev] OpenStack Swift deep dive code overview of DiskFile object refactoring - G+ Hangout, Wed. July 17th, 3 PM EDT

Peter Portante wrote: > We are hosting a G+ Hangout session for those interested in OpenStack > Swift to do an > overview, code walk-through, discussion and feedback on the proposed > DiskFile > refactoring changes to define as a supported API. Any particular reason (slides ?) why you're using a G

Re: [openstack-dev] Combination of ComputeCapabilitiesFilter and AggregateInstanceExtraSpecsFilter

Thanks a lot for your answers and for solving the issue. Regards, Jérôme On Mon, Jul 8, 2013 at 3:05 PM, Russell Bryant wrote: > On 07/05/2013 08:14 PM, Qiu Yu wrote: >> Russell, >> >> Should ComputeCapabilitiesFilter also be restricted to use scoped >> format only? Currently it recognize and co

Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

Mark, John, Nikola, Current in oslo we would like to put only 2 functions: 1) generic method for creating shadow table 2) generic method that the columns are same in shadow and main table So migration that adds shadow table could be done after all other works, when we finish improving of db-archi

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

Hi Brian, First thanks for the reviews and your detailed email. Second I will update the blueprint specs. as soon as possible, but for example it will look like that: Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source de

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Wed, 2013-07-10 at 19:49 -0400, Monty Taylor wrote: > I'd like top-post and hijack this thread for another exception related > thing: > > a) Anyone writing code such as: > > try: > blah() > except SomeException: > raise SomeOtherExceptionLeavingOutStackContextFromSomeException > > should

Re: [openstack-dev] [Keystone] How to write unit tests for db methods?

The methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used. I have implemented the things on the lines of trusts only.  Similar to trusts, I am also having RESTful APIs and unit tests for them are succesfully written. In test_ba

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Thu, Jul 11, 2013 at 10:50 AM, Mark McLoughlin wrote: > On Wed, 2013-07-10 at 21:14 +0200, Thomas Hervé wrote: > > > > > > On Wed, Jul 10, 2013 at 8:32 PM, Mark McLoughlin > > wrote: > > On Wed, 2013-07-10 at 11:01 -0700, Nachi Ueno wrote: > > > > > Personally, I prefer not to

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Thu, Jul 11, 2013 at 1:49 AM, Monty Taylor wrote: > I'd like top-post and hijack this thread for another exception related > thing: > > a) Anyone writing code such as: > > try: > blah() > except SomeException: > raise SomeOtherExceptionLeavingOutStackContextFromSomeException > > should be

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On 07/11/2013 05:43 AM, Thomas Hervé wrote: On Thu, Jul 11, 2013 at 1:49 AM, Monty Taylor mailto:mord...@inaugust.com>> wrote: I'd like top-post and hijack this thread for another exception related thing: a) Anyone writing code such as: try: blah() except SomeExcep

Re: [openstack-dev] [Keystone] Need help writing gate tests

On 07/10/2013 11:01 PM, Clark Boylan wrote: On Wed, Jul 10, 2013 at 7:32 PM, Adam Young wrote: I want to write 3 new Jenkins gate tests: Run the Keystone unit tests against 1. A live LDAP server 2. MySQL 3. Postgresql Right now, we know that the unit tests will fail against the live DBs, so

[openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

It looks like gate is down: https://jenkins.openstack.org/job/gate-tempest-devstack-vm-full/ https://bugs.launchpad.net/keystone/+bug/1200161 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/list

Re: [openstack-dev] OpenStack Swift deep dive code overview of DiskFile object refactoring - G+ Hangout, Wed. July 17th, 3 PM EDT

face-to-face discussions On Thu, Jul 11, 2013 at 5:12 AM, Thierry Carrez wrote: > Peter Portante wrote: > > We are hosting a G+ Hangout session for those interested in OpenStack > > Swift to do an > > overview, code walk-through, discussion and feedback on the proposed > > DiskFile > > refactori

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On 07/11/2013 05:06 AM, Thierry Carrez wrote: Sean Dague wrote: I think we need to get strict on projects and prevent them from capping their client requirements. That will also put burden on clients that they don't break backwards compatibility (which I think was a goal regardless). Indeed. T

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > On Wednesday, July 10, 2013, Sean Dague wrote: > > > Yesterday in the very exciting run around to figure out why the gate was > > broken, we realized something interesting. Because of the way the gate > > process pip requirements (one proje

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

good idea for global requirements Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin wrote: > On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > > On Wednesday, July 10,

Re: [openstack-dev] [Review] Use of exception for non-exceptional cases

On Thu, Jul 11, 2013 at 5:20 AM, Mark McLoughlin wrote: > > But I think what you're saying is missing is the stack trace from the > underlying exception. > > As I understood it, Python doesn't have a way of chaining exceptions > like this but e.g. Java does. A little bit more poking right now sho

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

On 07/11/2013 06:31 AM, Joe Gordon wrote: It looks like gate is down: https://jenkins.openstack.org/job/gate-tempest-devstack-vm-full/ https://bugs.launchpad.net/keystone/+bug/1200161 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org h

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

Hi Sean, > Cinder uncapping python-keystoneclient will get us past this. There is a review exactly proposing that: https://review.openstack.org/#/c/36344/ > Though I'm not > quite sure how we got to this break point in the first place. I think this is due to the django_openstack_auth breakag

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller wrote: > Hi Sean, > > > Cinder uncapping python-keystoneclient will get us past this. > > There is a review exactly proposing that: > > https://review.openstack.org/#/c/36344/ Actually for a number of reasons: https://review.openstack.org/#/c/36559/

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

On 07/11/2013 08:48 AM, John Griffith wrote: On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller mailto:d...@dmllr.de>> wrote: Hi Sean, > Cinder uncapping python-keystoneclient will get us past this. There is a review exactly proposing that: https://review.openstack.org/#/c/36344

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

On Thu, Jul 11, 2013 at 1:48 PM, John Griffith wrote: > > > > On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller wrote: > >> Hi Sean, >> >> > Cinder uncapping python-keystoneclient will get us past this. >> >> There is a review exactly proposing that: >> >> https://review.openstack.org/#/c/36344/ > > >

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

> Let's submit a multi-project bug on launchpad, and be serious for changing > these global requirements in following days https://bugs.launchpad.net/keystone/+bug/1200214 created. Greetings, Dirk ___ OpenStack-dev mailing list OpenStack-dev@lists.ope

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Hi Thierry, > Indeed. The whole idea behind a single release channel for python client > libraries was that you should always be running the latest, as they > should drastically enforce backward compatibility. Well, backward compatibility can be tricky when it comes to test. We've for example rec

[openstack-dev] [Ceilometer] Meeting agenda for Thu Jul 11rd at 1500 UTC

The Ceilometer project team holds a meeting in #openstack-meeting, see https://wiki.openstack.org/wiki/Meetings/MeteringAgenda for more details. Next meeting is on Thu Jul 11rd at 1500 UTC Please add your name with the agenda item, so we know who to call on during the meeting. * Action from prev

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin wrote: > On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > > On Wednesday, July 10, 2013, Sean Dague wrote: > > > > > Yesterday in the very exciting run around to figure out why the gate > was > > > broken, we realized something interesting

Re: [openstack-dev] The Gate is broken: all gate-tempest-devstack-* are failing

On Thu, Jul 11, 2013 at 7:01 AM, Sean Dague wrote: > On 07/11/2013 08:48 AM, John Griffith wrote: > >> >> >> >> On Thu, Jul 11, 2013 at 6:29 AM, Dirk Müller > > wrote: >> >> Hi Sean, >> >> > Cinder uncapping python-keystoneclient will get us past this. >> >> The

Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

On Thu, 2013-07-11 at 13:18 +0400, Boris Pavlovic wrote: > Mark, John, Nikola, > > > Current in oslo we would like to put only 2 functions: > > 1) generic method for creating shadow table > 2) generic method that the columns are same in shadow and main table > > > So migration that adds shadow

[openstack-dev] [Cinder] Bug Squash day, thanks!

Just wanted to thank all the folks that participated in the squash day yesterday!! We had a great turn out and had some new folks show up and pitch in which was great. We had a very successful go of it IMO, not only fixing quite a few bugs but find/fixing a number of new ones on the spot. The re

Re: [openstack-dev] Work around DB in OpenStack (Oslo, Nova, Cinder, Glance)

On Thu, Jul 11, 2013 at 7:51 AM, Mark McLoughlin wrote: > On Thu, 2013-07-11 at 13:18 +0400, Boris Pavlovic wrote: > > Mark, John, Nikola, > > > > > > Current in oslo we would like to put only 2 functions: > > > > 1) generic method for creating shadow table > > 2) generic method that the columns

Re: [openstack-dev] Change in openstack/neutron[master]: Add method to get iptables traffic counters

Hi Brian, You're right It could be easier with your approach to get and keep the traffic counters. I will add a new method to get the details of traffic counters of a chain. https://review.openstack.org/35624 Thoughts? Regards, Sylvain. - Original Message - From: "Sylvain Afchain" T

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On 07/11/2013 09:36 AM, Dolph Mathews wrote: On Thu, Jul 11, 2013 at 6:12 AM, Mark McLoughlin mailto:mar...@redhat.com>> wrote: On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > On Wednesday, July 10, 2013, Sean Dague wrote: > > > Yesterday in the very exciting run ar

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On 07/11/2013 09:12 AM, Dirk Müller wrote: Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days https://bugs.launchpad.net/keystone/+bug/1200214 Great! This is the first review we need to land to make progress: https://review

Re: [openstack-dev] [Keystone] How to write unit tests for db methods?

On 07/11/2013 05:23 AM, Akshat Kakkar wrote: The methods of read/write/update/delete of records in the tables are written using SQLalchemy only and no direct sql is used. I have implemented the things on the lines of trusts only. Similar to trusts, I am also having RESTful APIs and unit tes

Re: [openstack-dev] [Keystone] Need help writing gate tests

On 07/11/2013 06:30 AM, Sean Dague wrote: On 07/10/2013 11:01 PM, Clark Boylan wrote: On Wed, Jul 10, 2013 at 7:32 PM, Adam Young wrote: I want to write 3 new Jenkins gate tests: Run the Keystone unit tests against 1. A live LDAP server 2. MySQL 3. Postgresql Right now, we know that the un

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Hi Dirk, "Dirk Müller" wrote: > > Indeed. The whole idea behind a single release channel for python client > > libraries was that you should always be running the latest, as they > > should drastically enforce backward compatibility. > > Well, backward compatibility can be tricky when it comes t

Re: [openstack-dev] [Savanna-all] [savanna-all] merging savanna-extra elements

Matt, install.d is good place to install packages (like java and hadoop) and editing its configuration files. First scripts for Fedora was in subdirectory install.d too, but during installation I got error related to proc-trigger (input/output errors in proc-trigger). So I decided to change subdir

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

> In the corner to my left, our current largest gate reset culprit > appears to be neutron bug #1194026 - weighing in with 62 rechecks > since June 24th (http://status.openstack.org/rechecks/) So, with some of the highest rates of patch traffic we've seen over the last couple of weeks before the H

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith wrote: > > In the corner to my left, our current largest gate reset culprit > > appears to be neutron bug #1194026 - weighing in with 62 rechecks > > since June 24th (http://status.openstack.org/rechecks/) > > So, with some of the highest rates of patch

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

>> See for example https://bugs.launchpad.net/horizon/+bug/1196823 > This is arguably a deficiency of mox, which (apparently?) doesn't let us mock > properties automatically. I agree, but it is just one example. other test-only issues can happen as well. Similar problem: the *client packages are

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote: > > In the corner to my left, our current largest gate reset culprit > > appears to be neutron bug #1194026 - weighing in with 62 rechecks > > since June 24th (http://status.openstack.org/rechecks/) > > So, with some of the highest rates o

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On Thu, 2013-07-11 at 09:28 -0600, John Griffith wrote: > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith wrote: > > > > In the corner to my left, our current largest gate reset culprit > > > appears to be neutron bug #1194026 - weighing in with 62 rechecks > > > since June 24th (http://status.opensta

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On Jul 11, 2013, at 8:28 AM, John Griffith wrote: > > > > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith wrote: > > In the corner to my left, our current largest gate reset culprit > > appears to be neutron bug #1194026 - weighing in with 62 rechecks > > since June 24th (http://status.openstack.

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On 07/11/2013 11:46 AM, Mark McLoughlin wrote: > On Thu, 2013-07-11 at 09:28 -0600, John Griffith wrote: >> On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith wrote: >> In the corner to my left, our current largest gate reset culprit appears to be neutron bug #1194026 - weighing in with 62 reche

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On 07/11/2013 11:33 AM, Matthew Treinish wrote: On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote: In the corner to my left, our current largest gate reset culprit appears to be neutron bug #1194026 - weighing in with 62 rechecks since June 24th (http://status.openstack.org/rechecks/)

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On Thu, Jul 11, 2013 at 9:38 AM, Russell Bryant wrote: > On 07/11/2013 11:28 AM, John Griffith wrote: > > > > > > > > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith > > wrote: > > > > > In the corner to my left, our current largest gate reset culprit > > > appears

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On 07/11/2013 11:28 AM, John Griffith wrote: > > > > On Thu, Jul 11, 2013 at 9:16 AM, Dan Smith > wrote: > > > In the corner to my left, our current largest gate reset culprit > > appears to be neutron bug #1194026 - weighing in with 62 rechecks > > since

Re: [openstack-dev] AMQP Version upgrade plans?

- Original Message - > On 07/08/2013 10:51 AM, Ted Ross wrote: > > If someone from the Qpid community were to work on integrating the new > > AMQP 1.0 technology into OpenStack, where would be the right place to > > start? Would it be to add a new transport to oslo.messaging? > > I thin

Re: [openstack-dev] [Savanna-all] [savanna-all] merging savanna-extra elements

Ivan, Ok. I've gone through and successfully built and run an image using install.d on Fedora. Let me know if you still get the error using install.d. I hope it was just a transient issue. FYI, I used DIB at f6cc6bb1. Best, matt On 07/11/2013 11:02 AM, Ivan Berezovskiy wrote: Matt, inst

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On 07/11/2013 11:54 AM, Sean Dague wrote: On 07/11/2013 11:33 AM, Matthew Treinish wrote: On Thu, Jul 11, 2013 at 08:16:26AM -0700, Dan Smith wrote: In the corner to my left, our current largest gate reset culprit appears to be neutron bug #1194026 - weighing in with 62 rechecks since June 24th

Re: [openstack-dev] Bug #1194026

Adding openstack-dev to this discussion thread. Looks like the test is going to be skipped at the moment, but we probably need to consider raising the priority of this issue and assign our cores with more experience with tempest/gating on this. salvatore On 9 July 2013 22:48, Maru Newby wrote:

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

John Griffith wrote: > Well to be blunt, if there's not even anybody assigned to the defect and > it's significantly impacting > the progress of every other project. I don't know that it's such a bad > idea. There is someone assigned to it since it was raised at the release meeting. He doesn't se

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

Sean Dague wrote: > On 07/11/2013 11:54 AM, Sean Dague wrote: >> Let's start with the test skip. >> >> I am however pretty frustrated that we're really not getting anyone from >> neutron looking at this. We're at 121 rechecks (plus I'm sure there were >> plenty of no bug rechecks, I've seen a coupl

[openstack-dev] [keystone] sqlite doesn't support migrations

Just as a general statement, outside the scope of openstack, I don't think sqlite is intended to support schema evolution. From the sqlite docs [1]: "SQLite supports a limited subset of ALTER TABLE. [...] It is not possible to rename a column, remove a column, or add or remove constraints from a ta

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

Hi Sean Sorry for it taking long time to fixing this problem. At least, 3 neutron core dev is working on this issue, but it is kind of timing issue so we are struggling to replicate it. I'm also OK to move it for non-voting now. 2013/7/11 Thierry Carrez : > Sean Dague wrote: >> On 07/11/2013 11

[openstack-dev] [Glance] Meeting Reminder

Hi folks, We will be having a glance team meeting in #openstack-meeting-alt at 2000 UTC today. The main topic for today is figuring out what we need to do to get our last blueprints completed for the Havana 2 milestone. Please accept my apologies for the lateness of this reminder. markwash _

[openstack-dev] SQLAlchemy-migrate needs a new maintainer

Hi, Discussing with Jan Dittberner, who is upstream for sqlalchemy-migrate, it appears that he doesn't have time to maintain it. Is the OpenStack project willing to take over? Jan is ok to hand over everything, moving to Github, give access to Pypi, etc. Below is his reply to me when I asked him.

[openstack-dev] [Olso]About blueprint: Separate translation domain for log messages

Hi, Olso dev team I remember there was a blueprint discussed in the Havana summit to separate translation domains. https://blueprints.launchpad.net/oslo/+spec/log-messages-translation-domain I don't see any progress there. Do you have any plan to implement it? The translation team set the comman

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

OpenStack is currently divided. Older projects like Nova use sqlalchemy-migrate. Some newer projects like Neutron use alembic. I'd personally like to see everything in Alembic, but migrating all the Nova scripts in a way that didn't break compatibility will be a big challenge. It's easier f

[openstack-dev] [Savanna-all] Blueprints for EDP components

Hi, Blueprints for EDP components on launchpad are added https://blueprints.launchpad.net/savanna/+spec/job-manager-components https://blueprints.launchpad.net/savanna/+spec/data-discovery-component https://blueprints.launchpad.net/savanna/+spec/job-source-component https://blueprints.launchpad.n

Re: [openstack-dev] [Olso]About blueprint: Separate translation domain for log messages

Daisy, did you see Mark's response here: http://lists.openstack.org/pipermail/openstack-dev/2013-July/011692.html ? -Ben On 2013-07-11 13:32, Ying Chun Guo wrote: Hi, Olso dev team I remember there was a blueprint discussed in the Havana summit to separate translation domains. s:/

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

David Ripton, Alembic is much better and I think that it is better to extend it to provide sqlite, then to use and try to improve sqlalchemy-migrate. Also we are preparing old projects (Nova, Cinder and Glance) to move from sqlalchemy-migrate to something another (e.g. alembic). If you are intere

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On 07/11/2013 02:40 PM, David Ripton wrote: > OpenStack is currently divided. Older projects like Nova use > sqlalchemy-migrate. Some newer projects like Neutron use alembic. > > I'd personally like to see everything in Alembic, but migrating all the > Nova scripts in a way that didn't break c

[openstack-dev] [State-Management] Agenda for todays meeting at 2000 UTC

Hi all, The [state-management] project team holds a weekly meeting in #openstack-meeting on thursdays, 2000 UTC. The next meeting is today!!! As usual, everyone is welcome :-) Link: https://wiki.openstack.org/wiki/Meetings/StateManagement ## Agenda (30-60 mins): ## - Discuss any action items

Re: [openstack-dev] Current biggest OpenStack gate fail culprit - neutron bug #1194026

On 07/11/2013 01:37 PM, Nachi Ueno wrote: Hi Sean Sorry for it taking long time to fixing this problem. At least, 3 neutron core dev is working on this issue, but it is kind of timing issue so we are struggling to replicate it. I'm also OK to move it for non-voting now. Great. I think the foc

Re: [openstack-dev] DB team meeting Thursday 1900 UTC

On 07/10/2013 03:41 PM, David Ripton wrote: We don't have the DB team meeting every week, but we're having it this week. Thursday at 1900 UTC in #openstack-meeting. Thanks. We had the DB meeting today. Major things discussed were sqlalchemy-migrate maintainership crisis (it sounds like Ope

[openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

Hi, I think we should revert this patch that was added here ( https://review.openstack.org/#/c/29767/). What this patch does is when nova-compute calls into quantum to create the port it passes in the hostname on which the instance was booted on. The idea of the patch was that providing this infor

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On Thu, Jul 11, 2013 at 2:01 PM, Boris Pavlovic wrote: > David Ripton, > > Alembic is much better and I think that it is better to extend it to > provide sqlite, then to use and try to improve sqlalchemy-migrate. > > Also we are preparing old projects (Nova, Cinder and Glance) to move from > sqla

Re: [openstack-dev] [Nova] Criteria for compute drivers

This seems a fair way of doing it. Gives users and developers a fair warning. If its not tested, because we will keep breaking it by accident, and thats not fair on anyone, so those drivers shouldn't be in the main tree I wonder if we should requiring a certain level of testing or unit testing? L

Re: [openstack-dev] [Neutron] Campus Network Blueprint

Hi all, As requested in the ML2 meeting I worked out a new blueprint [1] specifying a subset of the Campus Network one eventually able to hit H3. I tried to make this blueprint the most generic I could, so I changed the concepts just a little bit. If you agree with this (even if not for H3) I will

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On 07/11/2013 03:12 PM, Monty Taylor wrote: > > > On 07/11/2013 02:40 PM, David Ripton wrote: >> OpenStack is currently divided. Older projects like Nova use >> sqlalchemy-migrate. Some newer projects like Neutron use alembic. >> >> I'd personally like to see everything in Alembic, but migrat

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On 07/12/2013 07:29 AM, Monty Taylor wrote: > We've got the upstream pypi and rtfd credentials now, the project should > be moved in to openstack systems soon enough. I also went through and > cleaned up build and test stuff work work like our stuff works (if we're > going to be maintaining it, we

[openstack-dev] [Openstack] Improve inject network configuration

Hi, stackers. When creating vm using multi nics, User should power up the second interface on the instance manually for use second IP. http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html I intend to fix interfaces.template file, so It can be possible power up oth

Re: [openstack-dev] AMQP Version upgrade plans?

On 07/11/2013 12:06 PM, William Henry wrote: > > > - Original Message - >> On 07/08/2013 10:51 AM, Ted Ross wrote: >>> If someone from the Qpid community were to work on integrating the new >>> AMQP 1.0 technology into OpenStack, where would be the right place to >>> start? Would it be t

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

Hey Aaron, As an interested party in the change, figured I'd take a stab at responding. I've talked with people at BigSwitch and Cisco about this change, so I know others are interested in this as well, but I'll let them give their perspective. At a high level, our goal at Arista is similar to wh

Re: [openstack-dev] [Openstack] Improve inject network configuration

On 07/11/2013 08:53 PM, Jae Sang Lee wrote: > Hi, stackers. > > When creating vm using multi nics, User should power up the second > interface on the instance manually for use second IP. > http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html > > I intend to fix in

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On 2013-07-12 08:01:58 +0800 (+0800), Thomas Goirand wrote: [...] > You might as well want to apply Fedora's patch (thanks to Pádraig Brady) > for SQLAlchemy 0.8: > http://pkgs.fedoraproject.org/cgit/python-migrate.git/commit/?id=603ed1d1 > > which was the reason I started the discussion with Jan

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

On 07/11/2013 08:01 PM, Thomas Goirand wrote: > On 07/12/2013 07:29 AM, Monty Taylor wrote: >> We've got the upstream pypi and rtfd credentials now, the project should >> be moved in to openstack systems soon enough. I also went through and >> cleaned up build and test stuff work work like our st

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

I agree with Andre's concerns around the implications of polling in what Aaron is proposing, and in fact, this is one reason the existing change is so nice. The ML2 sub-team talked about this at a recent meeting, and we liked the approach which Yong had taken with the patch. But as Andre says, w

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

I heard there's a talk about this issue in #openstack-infra last night (china standard time), what's the conclusion of that? BTW, how to find meeting log of #openstack-infra? I didn't find it in http://eavesdrop.openstack.org/ On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller wrote: > >> See for e

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On 07/11/2013 10:28 AM, Sean Dague wrote: > On 07/11/2013 09:12 AM, Dirk Müller wrote: >>> Let's submit a multi-project bug on launchpad, and be serious for >>> changing >>> these global requirements in following days >> >> https://bugs.launchpad.net/keystone/+bug/1200214 > > Great! > > This is

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

On 07/11/2013 11:38 PM, Gareth wrote: > I heard there's a talk about this issue in #openstack-infra last night > (china standard time), what's the conclusion of that? > > BTW, how to find meeting log of #openstack-infra? I didn't find it > in http://eavesdrop.openstack.org/ We don't log it curr

Re: [openstack-dev] SQLAlchemy-migrate needs a new maintainer

Hi all, As we should keep sqlalchemy-migrate in openstack, to at least 1 year. We could take care about it, to avoid tons of monkey patches in oslo:) 12.07.2013, в 6:08, Monty Taylor написал(а): > > > On 07/11/2013 08:01 PM, Thomas Goirand wrote: >> On 07/12/2013 07:29 AM, Monty Taylor wrote:

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Thanks, Monty but in my review https://review.openstack.org/#/c/36684/ , Doug said we will go without upper bound with those python-*clients and in this one https://review.openstack.org/#/c/36753/ , keystoneclient still keep '<0.4' and requirements test doesn't fail in keystoneclient ( https://jen

Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

so, what's the final conclusion about this issue? On Fri, Jul 12, 2013 at 12:11 PM, Gareth wrote: > Thanks, Monty > > but in my review https://review.openstack.org/#/c/36684/ , Doug said we > will go without upper bound with those python-*clients > and in this one https://review.openstack.org/#

Re: [openstack-dev] [Openstack] Improve inject network configuration

Russell Bryant wrote: On 07/11/2013 08:53 PM, Jae Sang Lee wrote: Hi, stackers. When creating vm using multi nics, User should power up the second interface on the instance manually for use second IP. http://docs.openstack.org/trunk/openstack-compute/admin/content/using-multi-nics.html I in

Re: [openstack-dev] Revert Pass instance host-id to Quantum using port bindings extension.

I agree with Andre and Kyle here. I am not sure that the polling option is even going to work for certain use cases where the host_id information is required when creating the port (for instance, to decide the VIF type). Thanks, ~Sumit. On Thu, Jul 11, 2013 at 7:27 PM, Kyle Mestery (kmestery) wr