[openstack-dev] [Neutron] - beware of layering mock patches

Hello all, A recent patch merged to remove all of the self.addCleanup(patch.stop) calls since we now have mock.patch.stopall in the cleanup of the base test case to do that work[1]. This introduced a couple of nondeterministic bugs that allowed it to sneak through the gate and block future patches

Re: [openstack-dev] [fuel] oddness with sqlalchemy db().refresh(object)

Igor, Ryan was able to repeat the issue in his env by checking out the patch set (5) with db().refresh(task_provision) enabled. On Sun, Apr 13, 2014 at 3:28 AM, Igor Kalnitsky wrote: > Hi guys, > > *@Roman*, we have > > db().refresh(task_provision) > > since the line above (self._call_silen

[openstack-dev] Efficient image cloning implementation in NetApp nfs drivers // make this part of base NFS driver

Hi All, I was going through the following blue print, NetApp proposed and implemented in its driver (NetAppNFSDriver - cinder/volume/drivers/netapp/nfs.py ) a while back (change): https://blueprints.launchpad.net/cinder/+spec/netapp-cinder-nfs-image-cloning It looks quite an interesting and val

[openstack-dev] [Nova] Thoughts from the PTL

First off, thanks for electing me as the Nova PTL for Juno. I find the outcome of the election both flattering and daunting. I'd like to thank Dan and John for running as PTL candidates as well -- I strongly believe that a solid democratic process is part of what makes OpenStack so successful, and

[openstack-dev] [heat][nova]dynamic scheduling

Hi, there has been a heated discussion about dynamic scheduling last week.(http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg21644.html) I am also interested in this topic. We believe that dynamic scheduling consists of two parts: balancing computing capacity and optimizing power c

Re: [openstack-dev] [horizon][heat] Unusable error messages in dashboard for Orchestration

On 11/04/14 22:24, Steven Hardy wrote: > Hi Tom, > > On Fri, Apr 11, 2014 at 01:05:00PM +0800, Tom Fifield wrote: >> Hi, >> >> Lodged a bug the day after Havana came out to hope to get this >> usability problem addressed. >> >> https://bugs.launchpad.net/horizon/+bug/1241395 >> >> Essentially, if s

Re: [openstack-dev] [Neutron] API list operations are not fast as they could because they're dumb

Hi Salvatore, > For this reason I am thinking we should what technically is a simple change: use policy checks determine the list of attributes to show only once for list response, and then re-use that list for the whole response. I'm +1 to this idea. Also, would it be too difficult to have some

Re: [openstack-dev] [infra][nova][docker]

On 12/04/14 04:45, Eric Windisch wrote: > > Any disagreements with that goal? > > > No disagreement at all. > > Not that we're talking yet about moving the driver back into Nova, I'd > like to take this opportunity to remind anyone interesting in > contributing a Cinder driver that it would

Re: [openstack-dev] [infra][nova][docker]

On 13/04/14 01:49, Russell Bryant wrote: > On 04/12/2014 02:27 PM, James E. Blair wrote: >> Michael Still writes: >> >>> Agreed, where it makes sense. In general we should be avoiding third >>> party CI unless we need to support something we can't in the gate -- a >>> proprietary virt driver, or w

Re: [openstack-dev] [infra][nova][docker]

On 11/04/14 21:03, Paul Czarkowski wrote: > Based on this feedback I have removed the docker portions of the review to > devstack > But have kept in the changes that make it easier for a nova drivers to add > their own > Files to the nova rootwrap.d directory. sounds good, I'll give it a go and upd

[openstack-dev] [sahara] Icehouse RC2 available

Hello everyone, Due to a number of issues critical for main functionality we've published new Icehouse release candidate for Sahara. Tarballs and bugfix lists are available at: https://launchpad.net/sahara/icehouse/icehouse-rc2 Unless release-critical regressions are found that warrant a releas

Re: [openstack-dev] [infra][nova][docker]

On 04/12/2014 03:24 PM, Sylvain Bauza wrote: > Hi Eric, > > > 2014-04-12 5:45 GMT+02:00 Eric Windisch >: > > > > > > > As for dockenstack, this might deserve a separate thread. What I've > done here is build something that may be useful to opensta

Re: [openstack-dev] [fuel] oddness with sqlalchemy db().refresh(object)

Hi guys, *@Roman*, we have db().refresh(task_provision) since the line above (self._call_silently) may change task status directly in db, not in SQLAlchemy session. *@Andrew*, it's really strange. I just checkout your request, return refreshing task and run tests. As a result, I have no fai

Re: [openstack-dev] [fuel] oddness with sqlalchemy db().refresh(object)

Hi Andrew, I believe, it's just the way SQLAlchemy Session works: all the changes you've made within a session aren't propagated to the db (read: no actual queries are issued) until you explicitly do: - flush(), or - commit() (as commit() calls flush() first), or - Query - one(), first(), all(),