Re: [openstack-dev] [Nova] Frustrations with review wait times

On Aug 28, 2013 9:42 AM, "Shawn Hartsock" wrote: > > tl;dr at the end... I can ramble on a bit. > > I agree with Daniel. > > I'm not a core reviewer, but I'm trying to think like one. Over the last few weeks I've divested myself of almost all coding tasks, instead trying to increase the size of th

Re: [openstack-dev] [Nova] Frustrations with review wait times

On Tue, Aug 27, 2013 at 11:04 AM, Daniel P. Berrange wrote: > On Tue, Aug 27, 2013 at 10:55:03AM -0400, Russell Bryant wrote: > > On 08/27/2013 10:43 AM, Daniel P. Berrange wrote: > > > I tend to focus the bulk of my review activity on the libvirt driver, > > > since that's where most of my knowle

Re: [openstack-dev] [Nova] Interested in a mid-Icehouse-cycle Nova meet-up?

On Mon, Aug 19, 2013 at 5:42 PM, Russell Bryant wrote: > Greetings, > > Some OpenStack programs have started a nice trend of getting together in > the middle of the development cycle. These meetups can serve a number > of useful purposes: community building, ramping up new contributors, > tackli

[openstack-dev] Updating global requirements -- pyflakes version conflict

. Several projects including tempest have begun doing this (https://review.openstack.org/#/c/43168/5). And because we have 53 repos in the openstack namespace (github.com/openstack) it is easier to send this out to hunt down 53 patches and add comments to them. best, Joe Gordon

Re: [openstack-dev] Code review study

On Tue, Aug 20, 2013 at 2:21 PM, Clint Byrum wrote: > Excerpts from Mark McLoughlin's message of 2013-08-20 03:26:01 -0700: > > On Thu, 2013-08-15 at 14:12 +1200, Robert Collins wrote: > > > This may interest data-driven types here. > > > > > > > https://www.ibm.com/developerworks/rational/librar

Re: [openstack-dev] [keystone] Two BPs for managing the tokens

On Aug 23, 2013 12:24 PM, "Dolph Mathews" wrote: > > > On Fri, Aug 23, 2013 at 10:51 AM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) wrote: >> >> Hello, >> >> >> >> I would think you would want to reuse the same token but update the expiration time as if it were the first time the token had be

Re: [openstack-dev] Proposal oslo.db lib

On Aug 19, 2013 8:35 AM, "Flavio Percoco" wrote: > > On 19/08/13 04:33 -0700, Gary Kotton wrote: >> >> So are you agree with next points? >> 1) In Havana focus on migrating in all projects to oslo.db code >> >> >> [Gary Kotton] It is worth going for. > > > +1 > > >> >> 2) in IceHouse create and mo

Re: [openstack-dev] Proposal oslo.db lib

On Fri, Aug 16, 2013 at 11:36 AM, Monty Taylor wrote: > > > On 08/16/2013 09:52 AM, Boris Pavlovic wrote: > > Hi all, > > > > We (OpenStack contributors) done a really huge and great work around DB > > code in Grizzly and Havana to unify it, put all common parts into > > oslo-incubator, fix bugs,

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes wrote: > On 08/18/2013 09:56 PM, Robert Collins wrote: > >> On 19 August 2013 10:43, Jay Pipes wrote: >> >>> On 08/18/2013 06:08 PM, Joshua Harlow wrote: >>> In my opinion (and just an opinion that I know everyone doesn't share) ORM

Re: [openstack-dev] Gate breakage process - Let's fix! (related but not specific to neutron)

On Sat, Aug 17, 2013 at 9:46 AM, Robert Collins wrote: > On 17 August 2013 23:49, Salvatore Orlando wrote: > > I tend to agree that when the gate for a project is broken, nothing > should > > be merged for that project until the gate jobs are green again. > > In the case of Neutron, making the jo

Re: [openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

On Aug 18, 2013 3:58 PM, "Jay Pipes" wrote: > > On 08/18/2013 03:53 AM, Joshua Harlow wrote: >> >> I always just liked SQL as the database abstraction layer ;) >> >> On a more serious note I think novas new object model might be a way to go but in all honesty there won't be a one size fits all sol

Re: [openstack-dev] Gate breakage process - Let's fix! (related but not specific to neutron)

On Aug 17, 2013 7:52 AM, "Salvatore Orlando" wrote: > > I tend to agree that when the gate for a project is broken, nothing should be merged for that project until the gate jobs are green again. > In the case of Neutron, making the job non voting only caused more bugs to slip through, and that mea

Re: [openstack-dev] Hacking 0.7 Released (for a bug fix)

On Thu, Aug 15, 2013 at 2:04 PM, Robert Collins wrote: > On 16 August 2013 08:33, Joe Gordon wrote: > > Hi All, > > > > Hacking 0.7 has just been released, and merged into > openstack/requirements > > (https://review.openstack.org/#/c/41523/), due to a bug in ha

[openstack-dev] Hacking 0.7 Released (for a bug fix)

/#/c/38851/2/tox.ini. best, Joe Gordon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] v3 api remove security_groups extension (was Re: security_groups extension in nova api v3)

On Thu, Aug 15, 2013 at 12:16 PM, Melanie Witt wrote: > On Aug 13, 2013, at 3:35 PM, Melanie Witt wrote: > > > On Aug 13, 2013, at 2:11 AM, Day, Phil wrote: > > > >> If we really want to get clean separation between Nova and Neutron in > the V3 API should we consider making the Nov aV3 API only ac

Re: [openstack-dev] Code review study

- On Thu, Aug 15, 2013 at 12:22 PM, Sam Harwell wrote: > I like to take a different approach. If my commit message is going to > take more than a couple lines for people to understand the decisions I > made, I go and make an issue in the issue tracker before committing locally > and then refe

Re: [openstack-dev] Swift, netifaces, PyPy, and cffi

On Tue, Aug 13, 2013 at 6:56 PM, Clint Byrum wrote: > Excerpts from Alex Gaynor's message of 2013-08-13 14:58:56 -0700: > > Hi all, > > > > (This references this changeset: https://review.openstack.org/#/c/38415/ > ) > > > > One of the goals I've been working at has been getting swift running on

Re: [openstack-dev] Blueprint review

On Thu, Aug 8, 2013 at 12:41 AM, Álvaro López García < alvaro.lopez.gar...@cern.ch> wrote: > Hi John. > > On Wed 07 Aug 2013 (15:56), Joe Gordon wrote: > > Can you provide more detail in the BP, there isn't very much to review > it > > on right now. > >

Re: [openstack-dev] Oslo.exception being dropped??

you no longer need to be "online" to have access to all information about the code repository. The commit message should be totally self-contained, to maintain that benefit. https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages > > From: Joe Gordon > R

Re: [openstack-dev] Oslo.exception being dropped??

This touches on one of my big pet peeves, in the commit message one should: "*Describe why a change is being made.* A common mistake is to just document how the code has been written, without describing /why/ the developer chose to do it that way. By all means describe the overall code structure,

Re: [openstack-dev] Dropping or weakening the 'only import modules' style guideline - H302

On Tue, Aug 6, 2013 at 1:44 PM, Morgan Fainberg wrote: > While I'm torn on this as a developer, it comes down to an ease of > understanding the code. In all cases, it is easier to understand where > something comes from if you only import modules. Enforcing the import of > modules tends to also

Re: [openstack-dev] [nova][glance] Future of nova's image API

It looks like everyone is in agreement on this, so here is the patch: https://review.openstack.org/#/c/40565/ On Tue, Aug 6, 2013 at 4:36 AM, Roman Bogorodskiy wrote: > Joe Gordon wrote: > > > On Mon, Aug 5, 2013 at 9:11 AM, Roman Bogorodskiy < > rbogorods...@mirant

Re: [openstack-dev] Blueprint review

Can you provide more detail in the BP, there isn't very much to review it on right now. On Wed, Aug 7, 2013 at 12:48 AM, Álvaro López García < alvaro.lopez.gar...@cern.ch> wrote: > Dear all. > > I've registered a blueprint [1] to improve and extend the current > image cache handler on the compu

Re: [openstack-dev] [nova][glance] Future of nova's image API

On Mon, Aug 5, 2013 at 9:11 AM, Roman Bogorodskiy wrote: > Joe Gordon wrote: > > > Hi All, > > > > even though Glance, has been pulled out of Nova years ago, Nova still > has a > > images API that proxies back to Glance. Since Nova is in the process of >

Re: [openstack-dev] [nova][glance] Future of nova's image API

On Mon, Aug 5, 2013 at 7:26 AM, John Garbutt wrote: > On 3 August 2013 03:07, Christopher Yeoh wrote: > > Some people had concerns about exposing the glance api publicly and so > > wanted to retain the images support in Nova. > > So the consensus seemed to be to leave the images support in, but

Re: [openstack-dev] [nova][glance] Future of nova's image API

e actually run nova with just the core API? > > Regards, > > Chris > > > > On Sat, Aug 3, 2013 at 6:54 AM, Joe Gordon <**joe.gord...@gmail.com** > ="mailto:joe.gord...@gmail.com";>> wrote: > >> Hi All, >> >> even though Glan

Re: [openstack-dev] Python overhead for rootwrap

On Fri, Aug 2, 2013 at 10:33 AM, Dan Smith wrote: > > Any solution where you need to modify sudoers every time the code > > changes is painful, because there is only one sudo configuration on a > > machine and it's owned by root. > > Hmm? At least on ubuntu there is a default /etc/sudoers.d direc

[openstack-dev] [nova][glance] Future of nova's image API

use Glance directly? I have vague concerns about making Glance API publicly accessible, but I am not sure what the underlying reason is * If it is still needed in Nova today, can we remove it in the future and if so what is the timeline? best, Joe Gordon

Re: [openstack-dev] Python overhead for rootwrap

On Aug 1, 2013 2:06 AM, "Thierry Carrez" wrote: > > Joe Gordon wrote: > > I tried > > swapping out rootwrap for sudo and that made the issue go away.So I > > think we should go back to supporting just using sudo instead of > > rootwrap, and make sure

Re: [openstack-dev] Python overhead for rootwrap

On Tue, Jul 30, 2013 at 8:55 AM, Thierry Carrez wrote: > Joe Gordon wrote: > > Going forward I think we should support two approaches: > > > > 1) some faster mostly python based (because we are a python project) > > rootwrap solution, there are many good ideas

Re: [openstack-dev] [Ironic] Nomination to add Chris Krelle to ironic core

+1 On Wed, Jul 31, 2013 at 9:41 AM, Lucas Alvares Gomes wrote: > +1 > > On Wed, Jul 31, 2013 at 5:29 PM, Anita Kuno wrote: > > I agree too. > > > > > > On 13-07-31 12:20 PM, Ghe Rivero wrote: > > > > +1 > > > > > > On Wed, Jul 31, 2013 at 6:10 PM, Devananda van der Veen > > wrote: > >> > >> Hi

Re: [openstack-dev] [Nova] Proposal to add Nikola Đipanov to nova-core

+1 On Wed, Jul 31, 2013 at 12:56 PM, Matt Riedemann wrote: > +1 > > > > Thanks, > > *MATT RIEDEMANN* > Advisory Software Engineer > Cloud Solutions and OpenStack Development > -- > *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889* > E-mail:* *mrie...@us.ibm.com*

Re: [openstack-dev] [savanna] scalable architecture

t; under well-defined API. > > I hope all the items above explain why we need Savanna as a separate > OpenStack service. > > > 3. Why can’t Savanna be used as a plugin for Heat? > It should be and it will be someday. > > > Regards, > Ruslan > > On Thu, Jul

Re: [openstack-dev] Python overhead for rootwrap

; Kevin > > From: John Garbutt [j...@johngarbutt.com] > Sent: Monday, July 29, 2013 2:38 AM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] Python overhead for rootwrap > > > Joe Gordon wrote: > > time python

Re: [openstack-dev] Python overhead for rootwrap

On Mon, Jul 29, 2013 at 5:51 AM, Thierry Carrez wrote: > John Garbutt wrote: > > I tend to agree that (option 3) aggregating all of the calls to > > rootwrap may be impractical: > >> Sean Dague wrote: > >> The reason there are 20 different call outs is that they aren't all in > the > >> same place

Re: [openstack-dev] Usage of mox through out the Openstack project.

On Jul 26, 2013 5:53 AM, "Russell Bryant" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/26/2013 05:35 AM, Roman Bogorodskiy wrote: > > Alex Meade wrote: > > > >> +1 to everything Russell just said and of course Blueprints for > >> this. One for #3 (changing from mox -> Mock)

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

On Wed, Jul 24, 2013 at 6:18 PM, Alex Glikson wrote: > Russell Bryant wrote on 24/07/2013 07:14:27 PM: > > > > > I really like your point about not needing to set things up via a config > > file. That's fairly limiting since you can't change it on the fly via > > the API. > > > True. As I point

Re: [openstack-dev] Python overhead for rootwrap

On Fri, Jul 26, 2013 at 11:34 AM, Jay Pipes wrote: > On 07/25/2013 04:21 PM, Joe Gordon wrote: > >> Hi All, >> >> We have recently hit some performance issues with nova-network. It >> turns out the root cause of this was we do roughly 20 rootwrapped shell >

[openstack-dev] Python overhead for rootwrap

p model. Any ideas? I am sending this email out to get the discussion started. best, Joe Gordon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [savanna] scalable architecture

On Jul 23, 2013 12:34 PM, "Sergey Lukjanov" wrote: > > Hi evereyone, > > We’ve started working on upgrading Savanna architecture in version 0.3 to make it horizontally scalable. > > The most part of information is in the wiki page - https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture. > >

[openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default

s.com/lists/openstack/operators/28599 Related bug: https://bugs.launchpad.net/tripleo/+bug/1178529 rate limiting is per process, and doesn't act as expected in a multi-process environment: https://review.openstack.org/#/c/36516/ best, Joe Gordon ___

Re: [openstack-dev] A simple way to improve nova scheduler

On Wed, Jul 24, 2013 at 12:24 PM, Russell Bryant wrote: > On 07/23/2013 06:00 PM, Clint Byrum wrote: > > This is really interesting work, thanks for sharing it with us. The > > discussion that has followed has brought up some thoughts I've had for > > a while about this choke point in what is sup

Re: [openstack-dev] A simple way to improve nova scheduler

> 2) latency > 3) one more service (memcached) > > So I am not sure that it is better then just send directly to scheduler > information. > > > Best regards, > Boris Pavlovic > --- > Mirantis Inc. > > > > > > > On Tue, Jul 23, 2013 at 11:56 PM,

Re: [openstack-dev] A simple way to improve nova scheduler

On Jul 23, 2013 3:44 PM, "Ian Wells" wrote: > > > * periodic updates can overwhelm things. Solution: remove unneeded updates, > > most scheduling data only changes when an instance does some state change. > > It's not clear that periodic updates do overwhelm things, though. > Boris ran the tests.

Re: [openstack-dev] A simple way to improve nova scheduler

But this concept may be useful in the future > > Just seems that real-time processing is a similar model as what is needed here. > > Maybe something like that is where this should end up? > > -Josh > > From: Joe Gordon > Reply-To: OpenStack Development Mailing List < o

Re: [openstack-dev] [Nova] support for multiple active scheduler policies/drivers

On Mon, Jul 22, 2013 at 3:04 PM, Russell Bryant wrote: > On 07/22/2013 05:15 PM, Alex Glikson wrote: > > Dear all, > > > > Following the initial discussions at the last design summit, we have > > published the design [2] and the first take on the implementation [3] of > > the blueprint adding sup

Re: [openstack-dev] A simple way to improve nova scheduler

consider where else it can help, other repercussions etc. > > By the way see one more time answers on your comments in doc. > > Best regards, > Boris Pavlovic > > Mirantis Inc. > > > > > > On Sat, Jul 20, 2013 at 3:14 AM, Joe Gordon wrote: > >> >

Re: [openstack-dev] A simple way to improve nova scheduler

On Fri, Jul 19, 2013 at 3:13 PM, Sandy Walsh wrote: > > > On 07/19/2013 05:36 PM, Boris Pavlovic wrote: > > Sandy, > > > > I don't think that we have such problems here. > > Because scheduler doesn't pool compute_nodes. > > The situation is another compute_nodes notify scheduler about their > > st

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

Along these lines, OpenStack is now maintaining sqlachemy-migrate, and we have our first patch up for better SQLite support, taken from nova, https://review.openstack.org/#/c/37656/ Do we want to go the direction of explicitly not supporting sqllite and not running migrations with it, like keyston

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

On Fri, Jul 12, 2013 at 1:57 AM, Robert Collins wrote: > On 11 July 2013 02:39, Russell Bryant wrote: > > >> We'll probably need something like this for Ironic with persistent > >> volumes on machines - yes its a rare case, but when it matters, it > >> matters a great deal. > > > > I believe you,

Re: [openstack-dev] Moving task flow to conductor - concern about scale

On Jul 19, 2013 9:57 AM, "Day, Phil" wrote: > > > -Original Message- > > From: Dan Smith [mailto:d...@danplanet.com] > > Sent: 19 July 2013 15:15 > > To: OpenStack Development Mailing List > > Cc: Day, Phil > > Subject: Re: [openstack-dev] Moving task flow to conductor - concern about > >

[openstack-dev] Hacking 0.6.0 Released

Hi All, I am pleased to announce we have just released version 0.6.0 of OpenStack's Style Guide tool, hacking. In addition to bug fixes version 0.6.0 introduces several new checks: H102: Apache 2.0 license header not found H103: header does not match Apache 2.0 License notice H231: Python 3.x in

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

e the >> release. >> >> I am available and thus +1 for either Aug 19/20 or Sep 16/17. >> >> From: Robert Collins [robe...@robertcollins.net] >> Sent: Monday, July 15, 2013 11:32 PM >> To: OpenStack Developmen

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

I am happy to help to but I don't have much extra bandwidth at the moment, so I can only play a supporting role as a core and not a leadership role. On Sat, Jul 13, 2013 at 2:58 PM, Michael Still wrote: > I'm happy to help, although I'm pretty busy... > > Michael > > On Fri, Jul 12, 2013 at 9:3

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

[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] 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] [Review] Use of exception for non-exceptional cases

On Wed, Jul 10, 2013 at 7:01 PM, Nachi Ueno wrote: > HI folks > > I would like to ask the review criteria in the community. > > Should we use exception for non-exceptional cases when we can use > parameter checking? > > Example1: Default value for array index > > try: >value = list[5] > exc

Re: [openstack-dev] [nova] Nova API extensions NOT to be ported to v3

On Fri, Jun 28, 2013 at 1:31 PM, Christopher Yeoh wrote: > Hi, > > The following is a list of API extensions for which there are no plans to > port. Please shout if you think any of them needs to be! > > baremetal_nodes.py > os_networks.py > networks_associate.py > os_tenant_networks.py > virtual

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

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 > block device is located or will be attached. Both solutions that l

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

On Tue, Jul 2, 2013 at 7:38 PM, Russell Bryant wrote: > Greetings, > > Nova includes various compute drivers today, but the test coverage they > receive varies quite a bit. This is documented on the following wiki > page. The drivers are broken up into groups A, B, and C. > > https://wiki.o

Re: [openstack-dev] Distro defaults [was Re: [oslo.config] Config files overriding CLI: The path of most surprise.]

On Tue, Jul 2, 2013 at 8:43 PM, Mark McLoughlin wrote: > On Tue, 2013-07-02 at 17:48 +, Jeremy Stanley wrote: > > On 2013-07-01 15:10:26 -0700 (-0700), Mark Washenberger wrote: > > [...] > > > The talk about permanence confuses me, unless we mean that more > > > permanent values are overridde

Re: [openstack-dev] HACKING and new-style relative imports

On Tue, Jul 9, 2013 at 1:28 PM, Kieran Spear wrote: > Hi all, > > There's a review up to make Horizon pass H304 (no relative imports): > > https://review.openstack.org/#/c/35664/ > > Old-style relative imports are dangerous, but I can't think of a good > enough reason to forbid new-style imports,

Re: [openstack-dev] [nova]Discussion of the inconsistency between api and backend compute driver limitations.

On Jul 3, 2013 12:44 PM, "guohliu" wrote: > > Hello, > > As we know, nova have different compute drivers with different limitations, you can see in this link, > > https://wiki.openstack.org/wiki/HypervisorSupportMatrix > > but the api doesn't reflect that, which means when the user performs some o

Re: [openstack-dev] [Nova] too many tokens

On Jul 3, 2013 5:22 PM, "Ala Rezmerita" wrote: > > Hi everyone, > > I have a question regarding too many token generation in nova when using quantumclient (also related to bug reports https://bugs.launchpad.net/nova/+bug/1192383 + https://bugs.launchpad.net/nova-project/+bug/1191159) > > For insta

Re: [openstack-dev] Proposal for including fake implementations in python-client packages

On Wed, Jul 3, 2013 at 6:19 PM, Christopher Armstrong < chris.armstr...@rackspace.com> wrote: > On Tue, Jul 2, 2013 at 11:38 PM, Robert Collins > wrote: > > Radix points out I missed the naunce that you're targeting the users > > of python-novaclient, for instance, rather than python-novaclient's

Re: [openstack-dev] Proposal for including fake implementations in python-client packages

On Mon, Jul 1, 2013 at 11:08 PM, Alex Gaynor wrote: > Hi all, > > I suspect many of you don't know me as I've only started to get involved in > OpenStack recently, I work at Rackspace and I'm pretty involved in other > Python > open source stuff, notably Django and PyPy, I also serve on the board

Re: [openstack-dev] Move keypair management out of Nova and into Keystone?

We should not remove it from the v3 API until we know this will be supported by keystone in Havana. best, Joe sent on the go On Jul 1, 2013 6:25 PM, "Mauro S M Rodrigues" wrote: > +1.. make sense to me, I always thought that was weird hehe > Say the word and we will remove it from v3. > > On 07

Re: [openstack-dev] [Nova] Nominating John Garbutt for nova-core

+1 On Wed, Jun 26, 2013 at 10:06 AM, Sean Dague wrote: > +1 > > > On 06/26/2013 11:09 AM, Russell Bryant wrote: > >> Greetings, >> >> I would like to nominate John Garbutt for the nova-core team. >> >> John has been involved with nova for a long time now. He's primarily >> known for his great

Re: [openstack-dev] [Nova][Heat] Where does "Shelving" belong

On Tue, Jun 25, 2013 at 10:38 AM, Andrew Laski wrote: > On 06/25/13 at 09:42am, Joe Gordon wrote: > >> On Tue, Jun 25, 2013 at 7:22 AM, Andrew Laski > >**wrote: >> >> I have a couple of reviews up to introduce the concept of shelving an >>> instance into No

Re: [openstack-dev] [Nova][Heat] Where does "Shelving" belong

On Tue, Jun 25, 2013 at 7:22 AM, Andrew Laski wrote: > I have a couple of reviews up to introduce the concept of shelving an > instance into Nova. The question has been raised as to whether or not this > belongs in Nova, or more rightly belongs in Heat. The blueprint for this > feature can be fo

Re: [openstack-dev] Termination of the title line of commit messages

On Jun 24, 2013 6:49 PM, "Russell Bryant" wrote: > > On 06/24/2013 08:14 PM, Angus Salkeld wrote: > > On 24/06/13 22:50 +0100, Mark McLoughlin wrote: > >> Hey, > >> > >> Pulling this out of gerrit for discussion. > >> > >> Background is one of my patches to diskimage-builder was -1ed because I > >

Re: [openstack-dev] defaults: making OpenStack work out of the box.

On Mon, Jun 24, 2013 at 3:46 PM, Monty Taylor wrote: > > > On 05/29/2013 08:48 AM, Doug Hellmann wrote: > > > > > > > > On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez > > wrote: > > > > Robert Collins wrote: > > > On the other hand, we're finding a large ch

Re: [openstack-dev] Termination of the title line of commit messages

On Mon, Jun 24, 2013 at 3:19 PM, Sean Dague wrote: > On 06/24/2013 06:15 PM, Monty Taylor wrote: > >> >> >> On 06/24/2013 05:56 PM, Mark McLoughlin wrote: >> >>> On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote: >>> Hey, Pulling this out of gerrit for discussion.

Re: [openstack-dev] The future of run_tests.sh

It sounds like the censuses in this thread is: In the long run, we want to kill run_tests.sh in favor of explaining how to use the underlying tools in a TESTING file. But in the short term, we should start moving toward using a TESTING file (such as https://review.openstack.org/#/c/33456/) but ke

Re: [openstack-dev] Add IDE specific directories to .gitignore

best, Joe sent on the go On Jun 18, 2013 2:29 AM, "Flavio Percoco" wrote: > > On 18/06/13 12:14 +0300, Roman Prykhodchenko wrote: >> >> Chmouel, >> >> Yes, it's possible to set up excluded directories in several ways. My question was why not make those directories excluded by default? >> > > I'd

Re: [openstack-dev] unittests on devstack hosts

best, Joe sent on the go On Jun 18, 2013 1:06 PM, "John Griffith" wrote: > > +1 on both A and B, I do this currently by installing test-requires via my setup script. IMO it's quite nice to do feature dev, function and unit testing all in one shot. +1 on both as well, we do call it devstack not

[openstack-dev] The future of run_tests.sh

Hi All, A patch to move the run_tests.sh script into oslo-incubator ( https://review.openstack.org/#/c/32736/), has brought up the bigger question of what is the future of './run_tests.sh.' This seems like a topic that directly affects all developers, so it sounded like it should be brought to th

<    4   5   6   7   8   9