[openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Hey Nova-istas, While I was hacking on [1] I was considering how to approach the fact that we now need to track one more thing (NUMA node utilization) in our resources. I went with - "I'll add it to compute nodes table" thinking it's a fundamental enough property of a compute host that it deserves

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/12/2014 04:49 PM, Sylvain Bauza wrote: > (sorry for reposting, missed 2 links...) > > Hi Nikola, > > Le 12/08/2014 12:21, Nikola Đipanov a écrit : >> Hey Nova-istas, >> >> While I was hacking on [1] I was considering how to approach the fact >> t

Re: [openstack-dev] [all] The future of the integrated release

On 08/13/2014 04:05 AM, Michael Still wrote: > On Wed, Aug 13, 2014 at 4:26 AM, Eoghan Glynn wrote: >> >>> It seems like this is exactly what the slots give us, though. The core >>> review >>> team picks a number of slots indicating how much work they think they can >>> actually do (less than the

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/13/2014 06:05 PM, Sylvain Bauza wrote: > > Le 13/08/2014 12:21, Sylvain Bauza a écrit : >> >> Le 12/08/2014 22:06, Sylvain Bauza a écrit : >>> >>> Le 12/08/2014 18:54, Nikola Đipanov a écrit : >>>> On 08/12/2014 04:49 PM, Sylvain Bauza w

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/13/2014 07:40 PM, Sylvain Bauza wrote: > > Le 13/08/2014 18:40, Brian Elliott a écrit : >> On Aug 12, 2014, at 5:21 AM, Nikola Đipanov wrote: >>> The problem can be described by the following lemma (if you take 'lemma' >>> to

Re: [openstack-dev] [nova] Retrospective veto revert policy

On 08/14/2014 11:11 AM, Daniel P. Berrange wrote: > On Thu, Aug 14, 2014 at 10:06:13AM +0100, Mark McLoughlin wrote: >> On Tue, 2014-08-12 at 15:56 +0100, Mark McLoughlin wrote: >>> Hey >>> >>> (Terrible name for a policy, I know) >>> >>> From the version_cap saga here: >>> >>> https://review.ope

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

On 08/14/2014 10:25 PM, Sylvain Bauza wrote: > Hi mikal, > > Le 14 août 2014 01:49, "Michael Still" > a écrit : >> >> So, there's been a lot of email in the last few days and I feel I am >> not keeping up. >> >> Sylvain, can you summarise for me what the plan is here? Ca

Re: [openstack-dev] [Nova] Concerns around the Extensible Resource Tracker design - revert maybe?

Since after a week of discussing it I see no compelling argument against reverting it - here's the proposal: https://review.openstack.org/115218 Thanks, N. On 08/12/2014 12:21 PM, Nikola Đipanov wrote: > Hey Nova-istas, > > While I was hacking on [1] I was considering how t

Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

On 08/19/2014 06:39 PM, Sylvain Bauza wrote: > On the other hand, ERT discussion is decoupled from the scheduler split > discussion and will be delayed until Extensible Resource Tracker owner > (Paul Murray) is back from vacation. > In the mean time, we're considering new patches using ERT as > non

Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

On 08/20/2014 08:27 AM, Joe Gordon wrote: > > On Aug 19, 2014 10:45 AM, "Day, Phil" <mailto:philip@hp.com>> wrote: >> >> > -Original Message- >> > From: Nikola Đipanov [mailto:ndipa...@redhat.com > <mailto:ndipa...@redhat.com&g

Re: [openstack-dev] [Nova] Scheduler split wrt Extensible Resource Tracking

On 08/20/2014 02:33 PM, Jay Pipes wrote: > On 08/20/2014 04:48 AM, Nikola Đipanov wrote: >> Fair enough - I will WIP the revert until Phil is back. It's the right >> thing to do seeing that he is away. > > Well, it's as much (or more?) Paul Murray and Andrea Rosa

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/02/2014 08:16 PM, Michael Still wrote: > Hi. > > We're soon to hit feature freeze, as discussed in Thierry's recent > email. I'd like to outline the process for requesting a freeze > exception: > > * your code must already be up for review > * your blueprint must have an approved sp

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/02/2014 09:23 PM, Michael Still wrote: > On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov wrote: >> On 09/02/2014 08:16 PM, Michael Still wrote: >>> Hi. >>> >>> We're soon to hit feature freeze, as discussed in Thierry's recent >>>

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/04/2014 02:07 AM, Joe Gordon wrote: > > > > On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov <mailto:ndipa...@redhat.com>> wrote: > > On 09/02/2014 09:23 PM, Michael Still wrote: > > On Tue, Sep 2, 2014 at 1:40 PM, Nikola Đipanov >

[openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

Hi team, I am requesting the exception for the feature from the subject (find specs at [1] and outstanding changes at [2]). Some reasons why we may want to grant it: First of all all patches have been approved in time and just lost the gate race. Rejecting it makes little sense really, as it ha

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/04/2014 03:36 AM, Dean Troyer wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Joe Gordon <mailto:joe.gord...@gmail.com>> wrote: > > On Wed, Sep 3, 2014 at 2:50 AM, Nikola Đipanov <mailto:ndipa...@redhat.com>> wrote: > > The reason many features

Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

On 09/04/2014 02:31 PM, Sean Dague wrote: > On 09/04/2014 07:58 AM, Nikola Đipanov wrote: >> Hi team, >> >> I am requesting the exception for the feature from the subject (find >> specs at [1] and outstanding changes at [2]). >> >> Some reasons why we may w

Re: [openstack-dev] [nova] FFE request serial-ports

On 09/04/2014 02:42 PM, Sahid Orentino Ferdjaoui wrote: > Hello, > > I would like to request a FFE for 4 changesets to complete the > blueprint serial-ports. > > Topic on gerrit: > > https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/serial-ports,n,z >

Re: [openstack-dev] [vmware][nova][FFE] vmware-spawn-refactor

On 09/04/2014 03:46 PM, Daniel P. Berrange wrote: > On Thu, Sep 04, 2014 at 02:09:26PM +0100, Matthew Booth wrote: >> I'd like to request a FFE for the remaining changes from >> vmware-spawn-refactor. They are: >> >> https://review.openstack.org/#/c/109754/ >> https://review.openstack.org/#/c/10975

Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

On 09/04/2014 04:51 PM, Murray, Paul (HP Cloud) wrote: > > > On 4 September 2014 14:07, Nikola Đipanov wrote: > > On 09/04/2014 02:31 PM, Sean Dague wrote: > >> On 09/04/2014 07:58 AM, Nikola Đipanov wrote: > >>> Hi team, > >>> > >>

Re: [openstack-dev] [nova] requesting an FFE for SRIOV

On 09/04/2014 05:16 PM, Dan Smith wrote: >> The main sr-iov patches have gone through lots of code reviews, manual >> rebasing, etc. Now we have some critical refactoring work on the >> existing infra to get it ready. All the code for refactoring and sr-iov >> is up for review. > > I've been doi

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/04/2014 11:23 AM, John Garbutt wrote: > Sorry for another top post, but I like how Nikola has pulled this > problem apart, and wanted to respond directly to his response. > Thanks John - I'm glad this caught your eye. > On 3 September 2014 10:50, Nikola Đipanov wrote: &

Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

On 09/04/2014 07:42 PM, Murray, Paul (HP Cloud) wrote: > > >> > >>> Anyway, not enough to -1 it, but enough to at least say something. > >> > >>> > >> > >> > >> > >> .. but I do not want to get into the discussion about software testing > >> > >> here, not the place really. > >>

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

On 09/04/2014 12:24 PM, Daniel P. Berrange wrote: > Position statement > == > > Over the past year I've increasingly come to the conclusion that > Nova is heading for (or probably already at) a major crisis. If > steps are not taken to avert this, the project is likely to loose > a

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

On 09/05/2014 01:26 AM, Jay Pipes wrote: > On 09/04/2014 10:33 AM, Dugger, Donald D wrote: >> Basically +1 with what Daniel is saying (note that, as mentioned, a >> side effect of our effort to split out the scheduler will help but >> not solve this problem). > > The difference between Dan's propo

Re: [openstack-dev] [Nova] Feature Freeze Exception process for Juno

On 09/04/2014 10:25 PM, Solly Ross wrote: > Anyway, I think it would be useful to have some sort of page where people > could say "I'm an SME in X, ask me for reviews" and then patch submitters > could go > and say, "oh, I need an someone to review my patch about storage backends, > let me > ask

Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

/2014-September/044669.html On 09/04/2014 01:58 PM, Nikola Đipanov wrote: > Hi team, > > I am requesting the exception for the feature from the subject (find > specs at [1] and outstanding changes at [2]). > > Some reasons why we may want to grant it: > > First of all all

Re: [openstack-dev] [Nova][FFE] Feature freeze exception for virt-driver-numa-placement

On 09/05/2014 05:20 PM, John Garbutt wrote: > On 5 September 2014 13:59, Nikola Đipanov wrote: >> Since this did not get an 'Approved' as of yet, I want to make sure that >> this is not because the number of sponsors. 2 core members have already >> sponsored it, a

Re: [openstack-dev] [Nova] What's holding nova development back?

On 09/13/2014 11:07 PM, Michael Still wrote: > Just an observation from the last week or so... > > The biggest problem nova faces at the moment isn't code review latency. > Our biggest problem is failing to fix our bugs so that the gate is > reliable. The number of rechecks we've done in the last

Re: [openstack-dev] [Nova] What's holding nova development back?

On 09/14/2014 12:27 AM, Boris Pavlovic wrote: > Michael, > > I am so glad that you started this topic. > I really like idea of of taking a pause with features and concentrating > on improvement of current code base. > > Even if the >1 k open bugs https://bugs.launchpad.net/nova are vital > iss

Re: [openstack-dev] [Nova] Proposal to re-add Dan Prince to nova-core

+1 On 26/11/13 20:32, Russell Bryant wrote: > Greetings, > > I would like to propose that we re-add Dan Prince to the nova-core > review team. > > Dan Prince has been involved with Nova since early in OpenStack's > history (Bexar timeframe). He was a member of the nova-core review team > from M

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

On 11/19/2013 05:52 PM, Peter Feiner wrote: > On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short > wrote: >> Hi >> >> >> On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner wrote: >>> >>> A substantive reason for switching from mox to mock is the derelict >>> state of mox releases. There hasn't been a rel

Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

On 12/04/2013 06:15 PM, Peter Feiner wrote: > On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov wrote: >> 1) Figure out what is the deal with mox3 and decide if owning it will >> really be less trouble than porting nova. To be hones - I was unable to >> even find the code repo

Re: [openstack-dev] [Nova] Future meeting times

On 12/18/2013 03:29 PM, Russell Bryant wrote: > Greetings, > > The weekly Nova meeting [1] has been held on Thursdays at 2100 UTC. > I've been getting some requests to offer an alternative meeting time. > I'd like to try out alternating the meeting time between two different > times to allow more

Re: [openstack-dev] [nova] How do we format/version/deprecate things from notifications?

On 12/18/2013 06:17 PM, Matt Riedemann wrote: > > > On 12/18/2013 9:42 AM, Matt Riedemann wrote: >> The question came up in this patch [1], how do we deprecate and remove >> keys in the notification payload? In this case I need to deprecate and >> replace the 'instance_type' key with 'flavor' pe

Re: [openstack-dev] [nova] New Websockify Release

On 02/27/2014 11:22 AM, Thierry Carrez wrote: > Solly Ross wrote: >> We (the websockify/noVNC team) have released a new version of websockify >> (0.6.0). It contains several fixes and features relating to OpenStack (a >> couple of bugs were fixed, and native support for the `logging` module was

Re: [openstack-dev] [Nova] Concrete Proposal for Keeping V2 API

On 03/03/2014 06:32 PM, Russell Bryant wrote: > There has been quite a bit of discussion about the future of the v3 API > recently. There has been growing support for the idea that we should > change course and focus on evolving the existing v2 API instead of > putting out a new major revision. T

Re: [openstack-dev] [nova] NUMA Cells

On 12/04/2014 05:30 AM, Michael Still wrote: > Hi, > > so just having read a bunch of the libvirt driver numa code, I have a > concern. At first I thought it was a little thing, but I am starting > to think its more of a big deal... > > We use the term "cells" to describe numa cells. However, tha

Re: [openstack-dev] [Nova] Spring cleaning nova-core

On 12/05/2014 01:05 AM, Michael Still wrote: > One of the things that happens over time is that some of our core > reviewers move on to other projects. This is a normal and healthy > thing, especially as nova continues to spin out projects into other > parts of OpenStack. > > However, it is import

Re: [openstack-dev] [Nova] Spring cleaning nova-core

On 12/07/2014 06:02 PM, Jay Pipes wrote: > On 12/07/2014 04:19 AM, Michael Still wrote: >> On Sun, Dec 7, 2014 at 7:03 PM, Gary Kotton wrote: >>> On 12/6/14, 7:42 PM, "Jay Pipes" wrote: >> >> [snip] >> -1 on pixelbeat, since he's been active in reviews on various things AFAICT in the la

Re: [openstack-dev] [Nova] Spring cleaning nova-core

On 12/07/2014 08:52 PM, Michael Still wrote: > > You know what makes me really sad? No one has suggested that perhaps > Padraig could just pick up his review rate a little. I've repeatedly > said we can re-add reviewers if that happens. > This is of course not true - everybody *but* the people o

Re: [openstack-dev] [nova][gate][stable] How eventlet 0.16.1 broke the gate

On 01/15/2015 10:35 AM, Joe Gordon wrote: > So how could we have avoided this problem? By capping stable branch > requirements so we only have to worry about uncapped dependencies on > master. Capping stable branches has been previous discussed but no > action has been taken. So going forward I pr

Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core

On 06/14/2014 12:40 AM, Michael Still wrote: > Greetings, > > I would like to nominate Ken'ichi Ohmichi for the nova-core team. > > Ken'ichi has been involved with nova for a long time now. His reviews > on API changes are excellent, and he's been part of the team that has > driven the new API w

[openstack-dev] [Nova] FFE request: clean-up-legacy-block-device-mapping

Hi folks, This did not make it in fully. Outstanding patches are: https://review.openstack.org/#/c/71064/ https://review.openstack.org/#/c/71065/ https://review.openstack.org/#/c/71067/ https://review.openstack.org/#/c/71067/ https://review.openstack.org/#/c/71479/ https://review.openstack.org/#

Re: [openstack-dev] [Nova] FFE Request: Image Cache Aging

On 03/05/2014 07:59 PM, Russell Bryant wrote: > On 03/05/2014 12:27 PM, Andrew Laski wrote: >> On 03/05/14 at 07:37am, Tracy Jones wrote: >>> Hi - Please consider the image cache aging BP for FFE >>> (https://review.openstack.org/#/c/56416/) >>> >>> This is the last of several patches (already merg

Re: [openstack-dev] [Nova] FFE Request: ISO support for the VMware driver

On 03/05/2014 08:00 PM, Russell Bryant wrote: > On 03/05/2014 10:34 AM, Gary Kotton wrote: >> Hi, >> Unfortunately we did not get the ISO support approved by the deadline. >> If possible can we please get the FFE. >> >> The feature is completed and has been tested extensively internally. The >> fea

Re: [openstack-dev] Add force detach to nova

On 03/27/2014 03:52 AM, Wanghao (S) wrote: > Hi, all, > > > > There is a use case: we have two nova components (call them nova A and > nova B) and one cinder component. Attach a volume to an instance in nova > A and then services of nova A become abnormal. > > Because the volume also want to b

Re: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient?

On 04/09/2014 03:54 AM, Lingxian Kong wrote: > yes, the bp also make sense to nova-cinder interaction, may I submmit > a blueprint about that? > > Any comments? > I was going to propose that same thing for Nova as well, as well as a summit session for Atlanta. Would be good to coordinate the

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

On 04/14/2014 08:58 AM, Chris Behrens wrote: > > On Apr 13, 2014, at 9:58 PM, Michael Still wrote: > >> First off, thanks for electing me as the Nova PTL for Juno. I find the > > First off, congrats! > Congrats Michael. And good luck! >> * a mid cycle meetup. I think the Icehouse meetup was

Re: [openstack-dev] [nova][cinder] create server from a volume snapshot, 180 reties is sufficient?

On 04/10/2014 04:01 PM, Lingxian Kong wrote: > 2014-04-10 15:06 GMT+08:00 sxmatch >: > > hi guys: > > I have registered a bp for this issue from Cinder side. > > https://blueprints.launchpad.net/cinder/+spec/send-volume-changed-notifications-to-nova >

Re: [openstack-dev] [nova] Nova Project Priorities for Kilo

On 10/07/2014 01:01 AM, Joe Gordon wrote: > Hi all, > > One of the outcomes of the nova midcyle meetup was to pick several > things for nova, as a team, to prioritize in Kilo. More background on > this can be found at [0] > > We are now collecting ideas for project priorities on this etherpad [1]

Re: [openstack-dev] [Nova] Cells conversation starter

On 10/20/2014 08:00 PM, Andrew Laski wrote: > One of the big goals for the Kilo cycle by users and developers of the > cells functionality within Nova is to get it to a point where it can be > considered a first class citizen of Nova. Ultimately I think this comes > down to getting it tested by de

Re: [openstack-dev] [nova] Pulling nova/virt/hardware.py into nova/objects/

On 10/20/2014 07:38 PM, Jay Pipes wrote: > Hi Dan, Dan, Nikola, all Nova devs, > > OK, so in reviewing Dan B's patch series that refactors the virt > driver's get_available_resource() method [1], I am stuck between two > concerns. I like (love even) much of the refactoring work involved in > Dan's

Re: [openstack-dev] Taking a break..

On 10/22/2014 07:37 PM, Chris Behrens wrote: > Hey all, > > Just wanted to drop a quick note to say that I decided to leave Rackspace to > pursue another opportunity. My last day was last Friday. I won’t have much > time for OpenStack, but I’m going to continue to hang out in the channels. > Ha

Re: [openstack-dev] [nova] Consistency, efficiency, and safety of NovaObject.save()

On 11/13/2014 02:45 AM, Dan Smith wrote: >> I’m not sure if I’m seeing the second SELECT here either but I’m less >> familiar with what I’m looking at. compute_node_update() does the >> one SELECT as we said, then it doesn’t look like >> self._from_db_object() would emit any further SQL specifi

Re: [openstack-dev] [Nova] Mid-cycle sprint for remote people ?

On 07/01/2014 03:40 PM, Sylvain Bauza wrote: > Hi, > > I won't be able to attend the mid-cycle sprint due to a good family > reason (a new baby 2.0 release expected to land by these dates), so I'm > wondering if it's possible to webcast some of the sessions so people who > are not there can still

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On 07/03/2014 05:27 PM, Mark McLoughlin wrote: > Hey > > This is an attempt to summarize a really useful discussion that Victor, > Flavio and I have been having today. At the bottom are some background > links - basically what I have open in my browser right now thinking > through all of this. >

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On 07/07/2014 02:58 PM, Victor Stinner wrote: > Hi, > > Le lundi 7 juillet 2014, 12:48:59 Nikola Đipanov a écrit : >> When I read all of this stuff and got my head around it (took some time >> :) ), a glaring drawback of such an approach, and as I mentioned on the >> sp

Re: [openstack-dev] [nova] fastest way to run individual tests ?

On 07/09/2014 10:51 PM, Matt Riedemann wrote: > > > On 6/12/2014 6:17 AM, Daniel P. Berrange wrote: >> On Thu, Jun 12, 2014 at 07:07:37AM -0400, Sean Dague wrote: >>> On 06/12/2014 06:59 AM, Daniel P. Berrange wrote: Does anyone have any tip on how to actually run individual tests in an

Re: [openstack-dev] [Nova] Boot from ISO feature status

On 07/29/2014 11:03 AM, Daniel P. Berrange wrote: > On Mon, Jul 28, 2014 at 09:30:24AM -0700, Vishvananda Ishaya wrote: >> I think we should discuss adding/changing this functionality. I have had >> many new users assume that booting from an iso image would give them a >> root drive which they coul

Re: [openstack-dev] [Nova] Nominating Jay Pipes for nova-core

On 07/30/2014 11:02 PM, Michael Still wrote: > Greetings, > > I would like to nominate Jay Pipes for the nova-core team. > > Jay has been involved with nova for a long time now. He's previously > been a nova core, as well as a glance core (and PTL). He's been around > so long that there are prob

Re: [openstack-dev] [all] The future of the integrated release

On 08/07/2014 03:20 PM, Russell Bryant wrote: > On 08/07/2014 09:07 AM, Sean Dague wrote:> I think the difference is > slot selection would just be Nova drivers. I >> think there is an assumption in the old system that everyone in Nova >> core wants to prioritize the blueprints. I think there are a

Re: [openstack-dev] [all] The future of the integrated release

On 08/08/2014 12:12 AM, Stefano Maffulli wrote: > On 08/07/2014 01:41 PM, Eoghan Glynn wrote: >> My point was simply that we don't have direct control over the >> contributors' activities > > This is not correct and I've seen it repeated too often to let it go > uncorrected: we (the OpenStack proj

Re: [openstack-dev] [all] The future of the integrated release

On 08/08/2014 11:37 AM, Thierry Carrez wrote: > Personally I think we just need to get better at communicating the > downstream expectations, so that if we create waste, it's clearly > upstream fault rather than downstream. Currently it's the lack of > communication that makes developers produce mo

Re: [openstack-dev] [nova] Deprecating CONF.block_device_allocate_retries_interval

On 08/06/2014 07:54 PM, Jay Pipes wrote: > I bring this up on the mailing list because I think Liyi's patch offers > an interesting future direction to the way that we think about our retry > approach in Nova. Instead of having hard-coded or configurable interval > times, I think Liyi's approach of

Re: [openstack-dev] [Jenkins} Gating broken

On 24/09/13 10:15, Gary Kotton wrote: > Hi, > Anyone know the root cause of: > > 2013-09-24 06:47:01.670 | Cleaning up... > 2013-09-24 06:47:01.670 | No distributions matching the version for > pyparsing>=2.0.1 (from cliff>=1.4.3->python-neutronclient>=2.3.0,<3->-r > /home/jenkins/workspace/gate

Re: [openstack-dev] [Jenkins} Gating broken

On 24/09/13 13:27, Sean Dague wrote: > > And to members of our community who are also maintainers of python > libraries, I'd ask that you please be really cognizant of when you move > requirements up major versions, and please us that as criteria to bump > your version numbers at least a minor lev

Re: [openstack-dev] [nova] BUG? nova-compute should delete unused instance files on boot

On 08/10/13 01:01, Russell Bryant wrote: > On 10/07/2013 06:34 PM, Vishvananda Ishaya wrote: >> There is a configuration option stating what to do with instances that are >> still in the hypervisor but have been deleted from the database. I think you >> want: >> >> running_deleted_instance_action

Re: [openstack-dev] [Nova] Blueprint review process

On 23/10/13 17:33, Russell Bryant wrote: > > 4) Blueprint Prioritization > > I would like to do a better job of using priorities in Icehouse. The > priority field services a couple of purposes: > > - helps reviewers prioritize their time > > - helps set expectations for the submitter for h

[openstack-dev] [Nova] Configuration validation

Hey all, During the summit session on the the VMWare driver roadmap, a topic of validating the passed configuration prior to starting services came up (see [1] for more detail on how it's connected to that specific topic). Several ideas were thrown around during the session mostly documented in [

Re: [openstack-dev] [Nova] Configuration validation

n > > On 11 November 2013 11:44, Nikola Đipanov wrote: >> Hey all, >> >> During the summit session on the the VMWare driver roadmap, a topic of >> validating the passed configuration prior to starting services came up >> (see [1] for more detail on how it's

Re: [openstack-dev] [Nova] Configuration validation

On 13/11/13 18:49, Doug Hellmann wrote: > > > > On Mon, Nov 11, 2013 at 6:08 PM, Mark McLoughlin <mailto:mar...@redhat.com>> wrote: > > Hi Nikola, > > On Mon, 2013-11-11 at 12:44 +0100, Nikola Đipanov wrote: > > Hey all, > > >

[openstack-dev] [Nova][db] Changing migrations

Dear OpenStack devs, A recent review [1] dragged into spotlight how damaging improper use of external code inside migrations can be. Basically in my mind the incident raises 2 issues that I think we should look into: 1) How can we make reviewing changes with db migrations more robust Since we u

Re: [openstack-dev] [Nova][db] Changing migrations

On 18/11/13 18:46, Nikola Đipanov wrote: > 1) How can we make reviewing changes with db migrations more robust > > Since we use sqlalchemy-migrate to version our database, the package's > documentation [2] states how care needs to be taken when importing code > inside a db

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

On 02/07/13 19:50, Boris Pavlovic wrote: > > *) DB Archiving > a) create shadow tables > b) add tests that checks that shadow and main table are synced. > c) add code that work with shadow tables. > Hi Boris & all, I have a few points regarding db archiving work that I am growi

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

what I think about DB archiving. > It is great things that helps us: > 1) to reduce migrations downtime > 2) to reduce count of rows in original table and improve performance > > And I think that tests that checks that "original" and "shadow" tables > ar

Re: [openstack-dev] About fixing old DB migrations

On 18/07/13 11:34, Boris Pavlovic wrote: > Hi all, > > I have some question about fixing old DB migrations. > > If we are now in havana. And some broken migration was added in Havana. > Why we are not able to fix it directly? > > Instead of chaining few lines, we should add new migration that

[openstack-dev] [Nova] review request for bp improve-block-device-handling

Hi folks, I'd greatly appreciate if we could get the remaining two patches reviewed and hopefully merged for the upcoming freeze this Wednesday. Both patches have been up for a long time and have seen a number of revisions and several +2 already. The patches in question are: https://review.opens

Re: [openstack-dev] [Nova] FFE Request: utilization aware scheduling

On 06/09/13 11:28, Thierry Carrez wrote: > Wang, Shane wrote: >> Hi core developers and everyone, >> >> Please allow me to make an FFE request for adding utilization aware >> scheduling support in Havana. >> >> The blueprint: >> https://blueprints.launchpad.net/nova/+spec/utilization-aware-schedu

Re: [openstack-dev] [nova] rebased after approval

On 06/09/13 14:12, Gary Kotton wrote: > Hi, > The following patch was approved but failed as it required a rebase > - https://review.openstack.org/#/c/41058/. Would it be possible that a > core reviewer takes a look. Re-approved. Cheers, N. > Thanks in advance > Gary > > > __

Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620

On 09/09/13 11:25, Roman Podolyaka wrote: > Hi, > > There is a patch on review (https://review.openstack.org/#/c/45422/) > fixing https://bugs.launchpad.net/tripleo/+bug/1221620 which has > importance 'Critical' in Nova and TripleO (long story short: currently > Nova Baremetal deployments with mor

Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620

I may propose a session on this for the summit. Cheers, N. > Anyway, TripleO-CI found this regression. Maybe we should consider > adding its job to Nova check/gate pipelines? > > Thanks, > Roman > > > On Mon, Sep 9, 2013 at 1:59 PM, Nikola Đipanov <mailto:nd

Re: [openstack-dev] [Nova][Baremetal][DB] Core review request: bugfix for 1221620

hink is wrong and should happen only in special cases like this (maybe, let's see :)), and not be something we do as a rule. If we want to be serious about performance - we can't keep on doing this - IMHO. N. > > Best regards, > Boris Pavlovic > > > > On Mon

Re: [openstack-dev] [Nova] Migration state machine proposal.

On 10/21/2015 10:17 PM, Joshua Harlow wrote: > Question on some things seen in the below paste. > > What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'? > > Why does it jump over 'reverting' or 'confirming'? Should it? > > The other question is the difference between 'failed' and

[openstack-dev] [Nova] SR-IOV subteam

Hello Nova, Looking at Mitaka specs, but also during the Tokyo design summit sessions, we've seen several discussions and requests for enhancements to the Nova SR-IOV functionality. It has been brought up during the Summit that we may want to organize as a subteam to track all of the efforts bett

Re: [openstack-dev] [nova] Proposal to add Sylvain Bauza to nova-core

On 11/06/2015 03:32 PM, John Garbutt wrote: > Hi, > > I propose we add Sylvain Bauza[1] to nova-core. > +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.

Re: [openstack-dev] [nova] Proposal to add Alex Xu to nova-core

On 11/06/2015 03:32 PM, John Garbutt wrote: > Hi, > > I propose we add Alex Xu[1] to nova-core. > +1 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?su

Re: [openstack-dev] [Nova] SR-IOV subteam

On 11/04/2015 07:56 AM, Moshe Levi wrote: > Maybe we can you use the pci- passthrough meeting slot > http://eavesdrop.openstack.org/#PCI_Passthrough_Meeting > It been a long time since we had a meeting. > I think that slot works well (at least for me). I'd maybe change the cadence to bi-weekly

Re: [openstack-dev] [Nova] [Neutron] SR-IOV subteam

review and comment. [1] http://eavesdrop.openstack.org/meetings/sriov/2015/sriov.2015-11-10-13.09.log.html On 11/10/2015 01:42 AM, Nikola Đipanov wrote: > On 11/04/2015 07:56 AM, Moshe Levi wrote: >> Maybe we can you use the pci- passthrough meeting slot >> http://eavesdro

Re: [openstack-dev] [oslo][messaging] configurable ack-then-process (at least/most once) behavior

On 11/30/2015 01:28 PM, Bogdan Dobrelya wrote: > Hello. > Please let's make this change [0] happen to the Oslo messaging. > This is reasonable, straightforward and backwards compatible change. And > it is required for OpenStack applications - see [1] - to implement a > sane HA. The only thing left

Re: [openstack-dev] [nova] bug 1550250: delete_on_termination" flag: how to proceed?

On 03/29/2016 09:14 AM, Markus Zoeller wrote: > The discussion around Bug 1550250 [1] doesn't show a clear path on how > to proceed. In short, it's about if we want to keep the flag > "delete_on_termination" for volumes which get migrated. Right now that > flag gets reset during the migration proce

[openstack-dev] [Nova] SR-IOV IRC meeting and sub-team - passing the torch

Hi team, As I'll be focusing on different things going forward, I was wondering if someone from the group of people who were normally working in this area would want to step up and take over the sub-team IRC meeting. It is normally not a massive overhead, mostly tracking ongoing efforts and patch

Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. race conditions)?

On 12/14/2015 08:20 AM, Cheng, Yingxin wrote: > Hi All, > > > > When I was looking at bugs related to race conditions of scheduler > [1-3], it feels like nova scheduler lacks sanity checks of schedule > decisions according to different situations. We cannot even make sure > that some fixes succ

Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. race conditions)?

On 12/15/2015 03:33 AM, Cheng, Yingxin wrote: > >> -Original Message- >> From: Nikola Đipanov [mailto:ndipa...@redhat.com] >> Sent: Monday, December 14, 2015 11:11 PM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [o

[openstack-dev] [Nova] PCI CI is down

Hey Nova, It seems the a bug [1] sneaked in that made the PCI CI jobs fail 100% of the time so they got turned off. Fix for the bug should be making it's way through the queue soon, but it was hinted on the review that there may be further problems. I'd like to help fix these issues ASAP as the r

Re: [openstack-dev] [Nova] PCI CI is down

; > -Original Message- > From: Nikola Đipanov [mailto:ndipa...@redhat.com] > Sent: Wednesday, January 20, 2016 4:41 PM > To: OpenStack Development Mailing List > Subject: [openstack-dev] [Nova] PCI CI is down > > Hey Nova, > > It seems the a bug [1] sneaked

Re: [openstack-dev] [nova] Better tests for nova scheduler(esp. race conditions)?

proper reasource accounting tests. Yingxin - in case you are still interested in doing some of this stuff, we can discuss here or on IRC. Thanks, Nikola On 12/15/2015 03:33 AM, Cheng, Yingxin wrote: > >> -Original Message- >> From: Nikola Đipanov [mailto:ndipa...@redh

[openstack-dev] [Nova] Device names supplied to the boot request

I'll keep this email brief since this has been a well known issue for some time now. Problem: Libvirt can't honour device names specified at boot for any volumes requested as part of block_device_mapping. What we currently do is in case they do get specified, we persist them as is, so that we can

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 11:24 AM, Sean Dague wrote: > On 07/15/2015 01:41 PM, Andrew Laski wrote: >> On 07/15/15 at 12:19pm, Matt Riedemann wrote: > >>> The other part of the discussion is around the API changes, not just >>> for libvirt, but having a microversion that removes the device from >>> the reques

Re: [openstack-dev] [Nova] Device names supplied to the boot request

On 07/16/2015 05:47 PM, Nikola Đipanov wrote: > > Also, not being able to specify device names would make it impossible to > implement certain features that EC2 API can provide, such as overriding > the image block devices without significant effort. > I forgot to add links that

  1   2   >