[openstack-dev] [CFP] FOSDEM 2019 IaaS and Virt DevRoom

Dear OpenStack community, FOSDEM 2019 will feature a Virtualization & IaaS DevRoom again. Here is the call for proposals. Please check it out if you would like to submit a talk. Regards, Kashyap --- We are excited to

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for 'T' release

On Mon, Sep 24, 2018 at 09:11:42AM -0700, iain MacDonnell wrote: > > > On 09/24/2018 06:22 AM, Kashyap Chamarthy wrote: > > (b) Oracle Linux: Can you please confirm if you'll be able to > > release libvirt and QEMU to 4.0.0 and 2.11, respectively? > > Hi Kash

[Openstack-operators] RFC: Next minimum libvirt / QEMU versions for 'T' release

Hey folks, Before we bump the agreed upon[1] minimum versions for libvirt and QEMU for 'Stein', we need to do the tedious work of picking the NEXT_MIN_* versions for the 'T' (which is still in the naming phase) release, which will come out in the autumn (Sep-Nov) of 2019. Proposal

[openstack-dev] RFC: Next minimum libvirt / QEMU versions for 'T' release

Hey folks, Before we bump the agreed upon[1] minimum versions for libvirt and QEMU for 'Stein', we need to do the tedious work of picking the NEXT_MIN_* versions for the 'T' (which is still in the naming phase) release, which will come out in the autumn (Sep-Nov) of 2019. Proposal

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Wed, Aug 22, 2018 at 11:03:43AM -0700, melanie witt wrote: [...] [Randomly jumping in on one specific point.] > Aside from that, it has always been difficult to add folks to > nova-core because of the large scope and expertise needed to approve > code across all of Nova. The complexity of

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Mon, Jun 11, 2018 at 10:14:33AM -0500, Eric Fried wrote: > I thought we were leaning toward the option where nova itself doesn't > impose a limit, but lets the virt driver decide. Yeah, I agree with that, if we can't arrive at a sensible limit for Nova, after testing with all drivers that

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Mon, Jun 11, 2018 at 11:55:29AM +0200, Sahid Orentino Ferdjaoui wrote: > On Fri, Jun 08, 2018 at 11:35:45AM +0200, Kashyap Chamarthy wrote: > > On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote: [...] > > > The 26 volumes thing is a libvirt

Re: [openstack-dev] [nova] increasing the number of allowed volumes attached per instance > 26

On Thu, Jun 07, 2018 at 01:07:48PM -0500, Matt Riedemann wrote: > On 6/7/2018 12:56 PM, melanie witt wrote: > > Recently, we've received interest about increasing the maximum number of > > allowed volumes to attach to a single instance > 26. The limit of 26 is > > because of a historical

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

On Tue, May 22, 2018 at 01:54:59PM -0500, Dean Troyer wrote: > StarlingX (aka STX) was announced this week at the summit, there is a > PR to create project repos in Gerrit at [0]. STX is basically Wind From a cursory look at the libvirt fork, there are some questionable choices. E.g. the config

Re: [openstack-dev] [StarlingX] StarlingX code followup discussions

On Tue, May 22, 2018 at 05:41:18PM -0400, Brian Haley wrote: > On 05/22/2018 04:57 PM, Jay Pipes wrote: [...] > > Please don't take this the wrong way, Dean, but you aren't seriously > > suggesting that anyone outside of Windriver/Intel would ever contribute > > to these repos are you? > > > >

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Mon, Apr 09, 2018 at 04:24:06PM -0500, Matt Riedemann wrote: > On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote: > > Keep in mind that Matt has a tendency to sometimes unfairly > > over-simplify others views;-). More seriously, c'mon Matt; I went out > > of my way to spen

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Mon, Apr 09, 2018 at 04:24:06PM -0500, Matt Riedemann wrote: > On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote: > > Keep in mind that Matt has a tendency to sometimes unfairly > > over-simplify others views;-). More seriously, c'mon Matt; I went out > > of my way to spen

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote: > On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: > > FWIW, I'd suggest so, if it's not too much maintenance. It'll just > > spare you additional bug reports in that area, and the overall default > > experience

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote: > On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote: > > FWIW, I'd suggest so, if it's not too much maintenance. It'll just > > spare you additional bug reports in that area, and the overall default > > experience

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Fri, Apr 06, 2018 at 06:07:18PM +0200, Thomas Goirand wrote: > On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote: [...] > > Note: You don't even have to build the versions from 'Buster', which are > > quite new. Just the slightly more conservative libvirt 3.2.0 and QEMU &g

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Fri, Apr 06, 2018 at 06:07:18PM +0200, Thomas Goirand wrote: > On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote: [...] > > Note: You don't even have to build the versions from 'Buster', which are > > quite new. Just the slightly more conservative libvirt 3.2.0 and QEMU &g

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Thu, Apr 05, 2018 at 06:11:26PM -0500, Matt Riedemann wrote: > On 4/5/2018 3:32 PM, Thomas Goirand wrote: > > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 > > is fine, please choose 3.0.0 as minimum. > > > > If you don't absolutely need new features from qemu 2.9.0

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Thu, Apr 05, 2018 at 06:11:26PM -0500, Matt Riedemann wrote: > On 4/5/2018 3:32 PM, Thomas Goirand wrote: > > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0 > > is fine, please choose 3.0.0 as minimum. > > > > If you don't absolutely need new features from qemu 2.9.0

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Thu, Apr 05, 2018 at 10:32:13PM +0200, Thomas Goirand wrote: Hey Zigo, thanks for the detailed response; a couple of comments below. [...] > backport of libvirt/QEMU/libguestfs more in details > --- > > I already attempted the backports from

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Thu, Apr 05, 2018 at 10:32:13PM +0200, Thomas Goirand wrote: Hey Zigo, thanks for the detailed response; a couple of comments below. [...] > backport of libvirt/QEMU/libguestfs more in details > --- > > I already attempted the backports from

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Sat, Mar 31, 2018 at 04:09:29PM +0200, Kashyap Chamarthy wrote: > [Meta comment: corrected the email subject: "Solar" --> "Stein"] Here's a change to get the discussion rolling: https://review.openstack.org/#/c/558171/ -- [RFC] Pick next minimum libvirt

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

On Sat, Mar 31, 2018 at 04:09:29PM +0200, Kashyap Chamarthy wrote: > [Meta comment: corrected the email subject: "Solar" --> "Stein"] Here's a change to get the discussion rolling: https://review.openstack.org/#/c/558171/ -- [RFC] Pick next minimum libvirt

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Stein" release

[Meta comment: corrected the email subject: "Solar" --> "Stein"] On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote: > The last version bump was in "Pike" release (commit: b980df0, > 11-Feb-2017), and we didn't do any bump during "Queens

Re: [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

[Meta comment: corrected the email subject: "Solar" --> "Stein"] On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote: > The last version bump was in "Pike" release (commit: b980df0, > 11-Feb-2017), and we didn't do any bump during "Queens

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

On Sat, Mar 31, 2018 at 03:17:52PM +0200, Kashyap Chamarthy wrote: > On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote: [...] > > > Taking the DistroSupportMatrix into picture, for the sake of discussion, > > > how about the following NEXT_MIN version

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

On Sat, Mar 31, 2018 at 03:17:52PM +0200, Kashyap Chamarthy wrote: > On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote: [...] > > > Taking the DistroSupportMatrix into picture, for the sake of discussion, > > > how about the following NEXT_MIN version

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote: > > While at it, we should also discuss about what will be the NEXT_MIN > > > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > > > spent going through

Re: [openstack-dev] [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote: > > While at it, we should also discuss about what will be the NEXT_MIN > > > > libvirt and QEMU versions for the "Solar" release. To that end, I've > > > > spent going through

[Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

The last version bump was in "Pike" release (commit: b980df0, 11-Feb-2017), and we didn't do any bump during "Queens". So it's time to increment the versions (which will also makes us get rid of some backward compatibility cruft), and pick future versions of libvirt and QEMU.

[openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Solar" release

The last version bump was in "Pike" release (commit: b980df0, 11-Feb-2017), and we didn't do any bump during "Queens". So it's time to increment the versions (which will also makes us get rid of some backward compatibility cruft), and pick future versions of libvirt and QEMU.

Re: [openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?

On Mon, Mar 26, 2018 at 12:28:02PM -0700, melanie witt wrote: > On Mon, 26 Mar 2018 14:12:52 -0500, Matt Riedemann wrote: > > On 3/26/2018 6:24 AM, ChangBo Guo wrote: > > > What's your use case for ListOpt, just make sure the value(a list) is > > > part of  'choices' ?   Maybe we need another

[openstack-dev] [oslo] Any reason why not have 'choices' parameter for ListOpt()?

Hi there, I was looking at oslo_config/cfg.py[*], and the StrOpt() class has 'choices' parameter, to allow a sequence of valid values / tuples of valid values for descriptions. However, I don't see the same 'choices' parameter for the ListOpt() class. Out of curiosity, is there a reason to not

Re: [openstack-dev] [nova] PTL Election Season

On Mon, Jan 22, 2018 at 05:09:31PM -0600, Matt Riedemann wrote: [...] > To anyone that cares, I don't plan on running for Nova PTL again for the > Rocky release. Queens was my fourth tour and it's definitely time for > someone else to get the opportunity to lead here. I don't plan on going >

Re: [openstack-dev] [all] Switching to longer development cycles

On Sat, Dec 16, 2017 at 08:16:13AM -0600, Matt Riedemann wrote: > On 12/16/2017 5:51 AM, Kashyap Chamarthy wrote: Hi Matt, First, thanks for the detailed reply with specific examples. [...] > > But one pontential question that comes to mind from that old thread is > > how is th

Re: [openstack-dev] [all] Switching to longer development cycles

On Thu, Dec 14, 2017 at 12:02:13PM +0100, Kashyap Chamarthy wrote: > On Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: [...] > > What it means: > > > > - We'd only do one *coordinated* release of the OpenStack components > > per year, and maintain

Re: [openstack-dev] [all] Switching to longer development cycles

On Fri, Dec 15, 2017 at 10:11:24AM +0800, Zhenyu Zheng wrote: > On Thu, Dec 14, 2017 at 7:02 PM, Kashyap Chamarthy <kcham...@redhat.com> > wrote: [...] > > For a relatively mature (~7 years; and ~5 years if we count from the > > time governance changed to OpenStack

Re: [openstack-dev] [all] Switching to longer development cycles

On Wed, Dec 13, 2017 at 05:17:26PM +0100, Thierry Carrez wrote: > Hi everyone, Hey Thierry, > Over the past year, it has become pretty obvious to me that our > self-imposed rhythm no longer matches our natural pace. It feels like we > are always running elections, feature freeze is always just

Re: [openstack-dev] FOSDEM 2018: Call For Proposals: Virtualization & IaaS DevRoom

On Mon, Nov 06, 2017 at 01:37:10PM +0100, Kashyap Chamarthy wrote: > I'm delighted to announce that the call for proposals is now open for > the Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be > hosted on February 3 and 4, 2018. > > This year will mark FOSDEM

[openstack-dev] FOSDEM 2018: Call For Proposals: Virtualization & IaaS DevRoom

I'm delighted to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be hosted on February 3 and 4, 2018. This year will mark FOSDEM’s 18th anniversary as one of the longest-running free and open source software developer events,

[Openstack-operators] Call For Proposals: KVM Forum 2017 [Submission deadline: 15-JUN-2017]

KVM Forum 2017: Call For Participation October 25-27, 2017 - Hilton Prague - Prague, Czech Republic (All submissions must be received before midnight June 15, 2017) =

[openstack-dev] Call For Proposals: KVM Forum 2017 [Submission deadline: 15-JUN-2017]

KVM Forum 2017: Call For Participation October 25-27, 2017 - Hilton Prague - Prague, Czech Republic (All submissions must be received before midnight June 15, 2017) =

Re: [openstack-dev] [nova] Next minimum libvirt version

On Thu, Feb 09, 2017 at 05:29:22PM -0600, Matt Riedemann wrote: > Since danpb hasn't been around I've sort of forgotten about this, but we > should talk about bumping the minimum required libvirt version in nova. > > Currently it's 1.2.1 and the next was set to 1.2.9. > > On master we're gating

[openstack-dev] FOSDEM 2017: Call For Proposals -- Virtualization & IaaS DevRoom

=== The call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2017, to be hosted on February 4, 2017. This year will mark FOSDEM’s 17th anniversary as one of the longest-running free and

Re: [openstack-dev] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?

On Tue, Oct 11, 2016 at 05:53:24PM +0200, Thomas Goirand wrote: > On 10/11/2016 02:09 PM, Markus Zoeller wrote: > > * How to create a "*.deb" package out of the source code of > > libvirt/qemu? (surprisingly enough, I'm still struggling with this) > > What version of libvirt / qemu are you trying

Re: [openstack-dev] [devstack] devstack-plugin additional-pkg-repos: ocata summit working session?

On Tue, Oct 11, 2016 at 02:09:33PM +0200, Markus Zoeller wrote: [Snip well-written backrgound detail] > Request > --- > My question is, if you have interest in this plugin and its > capabilities, are you at the Summit in Barcelona and do you have time > for a short working session there?

Re: [openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

On Fri, Oct 07, 2016 at 03:32:14PM -0500, Matt Riedemann wrote: > On 10/6/2016 7:58 AM, Kashyap Chamarthy wrote: > > - > > We expose the state of the copy job in the XML and forward the READY > > event f

Re: [openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

On Thu, Oct 06, 2016 at 09:29:41AM -0500, Eric Blake wrote: > On 10/06/2016 07:58 AM, Kashyap Chamarthy wrote: > > On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote: > >> TL;DR > >> - > >> > >> From the debug analysis of

Re: [openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

On Thu, Oct 06, 2016 at 01:32:39AM +0200, Kashyap Chamarthy wrote: > TL;DR > - > > From the debug analysis of the log below, and discussion with Eric Blake > of upstream QEMU / libvirt resulted in the below bug report: > > https://bugzilla.redhat.com/sh

[openstack-dev] [nova] [libvirt] Debugging blockRebase() - "active block copy not ready for pivot"

TL;DR - >From the debug analysis of the log below, and discussion with Eric Blake of upstream QEMU / libvirt resulted in the below bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1382165 -- virDomainGetBlockJobInfo: Adjust job reporting based on QEMU stats & the "ready" field

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: > The said patch in question fixes a CVE[x] in stable/liberty. > > We currently have two options, both of them have caused an impasse with > the Nova upstream / stable maintainers. We've had two-ish months to

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

On Thu, Sep 22, 2016 at 04:25:00PM +1000, Tony Breeds wrote: > On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote: > > > Well, the risk profile of what has to be changed for stable/liberty > > (given that all the actual code is buried in libraries which have tons > > of other changes).

Re: [openstack-dev] [nova] ops meetup feedback

On Tue, Sep 20, 2016 at 04:20:49PM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 11:01:23AM -0400, Sean Dague wrote: [...] > > Here is my reconstruction of the snapshot issue from what I can remember > > of the conversation. > > > > Nova defaults to live snapshots. This uses the

Re: [openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: [...] > > The two options at hand: > > > > (1) Nova backport from master (that also adds a check for the presence > > of 'Pro

[openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

The said patch in question fixes a CVE[x] in stable/liberty. We currently have two options, both of them have caused an impasse with the Nova upstream / stable maintainers. We've had two-ish months to mull over this. I'd prefer to get this out of a limbo, & bring this to a logical conclusion.

Re: [openstack-dev] [nova] Bug team meeting

On Tue, Sep 06, 2016 at 03:41:04PM -0700, Augustina Ragwitz wrote: > I should add that I also expressed interest in taking over the Bug Czar > role. I've been actively involved with the bugs team since Markus > revived it earlier this year. I've run meetings when he was unavailable > and also

Re: [openstack-dev] [devstack] libvirt/qemu source install plugin.

On Thu, Jul 21, 2016 at 02:25:46PM +0200, Markus Zoeller wrote: > On 20.07.2016 22:38, Mooney, Sean K wrote: > > Hi > > I recently had the need to test a feature (vhost-user reconnect) > > that was commit to the qemu source tree a few weeks ago. As there > > has been no release since then I needed

Re: [openstack-dev] [kolla][nova][infra] Voting gates

On Thu, Jul 14, 2016 at 03:19:39PM -0500, Matt Riedemann wrote: > On 7/14/2016 11:34 AM, Paul Bourke wrote: > > Hi Matt, > > > > Here is the failure from nova_compute on trying to start an instance: [...] > > 2016-07-13 18:04:12.634968 | 2016-07-13 18:01:34.560 1 ERROR > > oslo_service.service

Re: [openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?

On Fri, Jul 01, 2016 at 02:35:34PM +, Jeremy Stanley wrote: > On 2016-07-01 15:39:10 +0200 (+0200), Kashyap Chamarthy wrote: > > [Snip description of some nice debugging.] > > > > > I'd really love it if there was > > > > > > 1. the ability to

Re: [openstack-dev] [nova][infra][ci] bulk repeating a test job on a single review in parallel ?

On Thu, Jun 30, 2016 at 02:44:36PM +0100, Daniel P. Berrange wrote: [Snip description of some nice debugging.] > I'd really love it if there was > > 1. the ability to request checking of just specific jobs eg > > "recheck gate-tempest-dsvm-multinode-full" Yes, this would really be

Re: [openstack-dev] [nova] A primer on data structures used by Nova to represent block devices

On Thu, Jun 16, 2016 at 12:48:18PM +0100, Matthew Booth wrote: > The purpose of this mail is to share what I have learned about the various > data structures used by Nova for representing block devices. I compiled > this for my own use, but I hope it might be useful for others, and that > other

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

On Thu, May 26, 2016 at 10:55:47AM -0400, Sean Dague wrote: > On 05/26/2016 05:38 AM, Kashyap Chamarthy wrote: > > On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote: > > > > [...] > > > >> So, in short, the central issue seems to be

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

On Wed, May 25, 2016 at 05:42:04PM +0200, Kashyap Chamarthy wrote: [...] > So, in short, the central issue seems to be this: the custom 'gate64' > model is not being trasnalted by libvirt into a model that QEMU can > recognize. An update: Upstream libvirt points out that t

Re: [openstack-dev] [gate] [nova] live migration, libvirt 1.3, and the gate

On Tue, May 24, 2016 at 01:59:17PM -0400, Sean Dague wrote: Thanks for the summary, Sean. [...] > It turns out it works fine because libvirt *actually* seems to take the > data from cpu_map.xml and do a translation to what it believes qemu will > understand. On these systems apparently this

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

On Tue, May 03, 2016 at 02:27:00PM -0500, Sergio Cuellar Valdes wrote: [...] > I'm confused too about the use of KVM or QEMU In the computes the > file​/etc/nova/nova-compute.conf has: > > virt_type=kvm > > The output of: > > nova hypervisor-show | grep hypervisor_type > > is: > >

Re: [openstack-dev] [devstack] - suggested development workflow without ./rejoin-stack.sh ?

On Mon, May 02, 2016 at 03:10:56PM -0700, Kevin Benton wrote: > This patch removed the ./rejoin-stack.sh script: > https://review.openstack.org/#/c/291453/ > > I relied on this heavily in my development VM which sees lots of restarts > because of various things (VM becomes unresponsive in load

Re: [openstack-dev] [all][elections] Results of the TC Election

On Fri, Apr 08, 2016 at 03:14:33PM +0200, Thierry Carrez wrote: [...] > Long term I'd like to remove the summit pass perk (or no longer link > it to "one commit"). Agreed. FWIW, I recall discussing this in the hallways of the Paris Summit, and suggesting something like 3-5 commits and someway

Re: [openstack-dev] [nova] working on bug reports; what blocks you?

On Fri, Mar 18, 2016 at 07:01:34PM +0100, Markus Zoeller wrote: > Kashyap Chamarthy <kcham...@redhat.com> wrote on 03/18/2016 07:28:09 AM: [...] > > Writing a thoughtful report is hard and time-taking. > > Yeah, and I assume that's the reason many bug reports lack that

Re: [openstack-dev] [nova] working on bug reports; what blocks you?

On Thu, Mar 17, 2016 at 03:28:48PM -0500, Matt Riedemann wrote: > On 3/17/2016 11:41 AM, Markus Zoeller wrote: > >What are the various reasons which block you to work on bug reports? > >This question goes especially to the new contributors but also to the > >rest of us. For me, personally, it's

Re: [openstack-dev] [nova] Wishlist bugs == (trivial) blueprint?

On Tue, Mar 15, 2016 at 05:59:32PM +, Tim Bell wrote: [...] > The bug process was very light weight for an operator who found > something they would like enhanced. It could be done through the web > and did not require git/gerrit knowledge. I went through the process > for a change: > > -

Re: [openstack-dev] [Nova] Update on live migration priority

On Fri, Feb 12, 2016 at 04:21:27PM +, Murray, Paul (HP Cloud) wrote: > This time with a tag in case anyone is filtering... Yep, I was filtering, and would've missed it without your tag. :-) > From: Murray, Paul (HP Cloud) > Sent: 12 February 2016 16:16 > To: openstack-dev@lists.openstack.org

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

On Thu, Jan 21, 2016 at 06:37:00PM +0100, Markus Zoeller wrote: > Flavio Percoco wrote on 01/21/2016 09:13:02 AM: [...] First, positive remark(s): Thanks for writing this up. FWIW, I support the notion of having milestones focusing on stability, as opposed to explicitly

Re: [openstack-dev] [nova][infra] Ability to run newer QEMU in Gate jobs

On Wed, Jan 20, 2016 at 10:25:00AM +, Tony Breeds wrote: > On Tue, Jan 19, 2016 at 06:11:35PM +, Daniel P. Berrange wrote: > > > We'll almost certainly need to be able to test QEMU 2.6 in the N > > release cycle, since that'll (hopefully) include support for TLS > > encrypted

[openstack-dev] [nova][infra] Ability to run newer QEMU in Gate jobs

Heya, Currently the live migration test job[1] is using relatively old version of QEMU (2.0 -- 2 years old, 17-APR-2014). And, libvirt 1.2.2 (released on 02-MAR-2014). For libvirt, I realize there's an in-progress thread[2] to get to a state to run a bleeding edge libvirt. How can we go about

Re: [openstack-dev] [nova][libvirt] VIR_MIGRATE_NON_SHARED_INC works more like full copy in block migration ?

On Sun, Jan 10, 2016 at 06:07:33PM +0800, Luo Gangyi wrote: > Hi devs, > > > Do you test the difference between within and without > VIR_MIGRATE_NON_SHARED_INC ? > > > When I add VIR_MIGRATE_NON_SHARED_INC in block_migration_flags in > nova, nova block migration behaves more like a full copy

Re: [openstack-dev] [nova][infra] Getting a bleeding edge libvirt gate job running

On Wed, Nov 18, 2015 at 06:46:58AM +1100, Ian Wienand wrote: > On 11/18/2015 06:10 AM, Markus Zoeller wrote: > This > >was a trigger to see if we can create a gate job which utilizes the > >latest, bleeding edge, version of libvirt to test such features. > > >* Is already someone working on

Re: [openstack-dev] [nova][bugs] Weekly Status Report

On Mon, Nov 09, 2015 at 04:55:12PM +0100, Markus Zoeller wrote: > Kashyap Chamarthy <kcham...@redhat.com> wrote on 11/06/2015 06:37:08 PM: > > > From: Kashyap Chamarthy <kcham...@redhat.com> > > To: "OpenStack Development Mailing List (not for us

Re: [openstack-dev] [nova][bugs] Weekly Status Report

On Fri, Nov 06, 2015 at 05:54:59PM +0100, Markus Zoeller wrote: > Hey folks, > > below is the first report of bug stats I intend to post weekly. > We discussed it shortly during the Mitaka summit that this report > could be useful to keep the attention of the open bugs at a certain > level. Let

Re: [openstack-dev] [Nova] live migration sub-team meeting

On Tue, Nov 03, 2015 at 12:18:38PM +, Murray, Paul (HP Cloud) wrote: > Hi all, > > Live migration was confirmed as a Nova priority for the Mitaka cycle > and a sub-team section can be found on the priorities tracking page > [1]. > > Most team members expressed they would like a regular IRC

Re: [openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

On Sat, Oct 31, 2015 at 09:11:31AM +0900, Davanum Srinivas wrote: > Matt, > > 0.6.0 and 0.7.0 were released for Mitaka! not Liberty. Though yes, because > of not having pins any library we release for Mitaka will end up being used > with Liberty as well. >

Re: [Openstack-operators] raw ephemeral disks and qcow2 images

rom other Nova developers who're more familiar with the intricacies of qcow2 cache configuration. > > -Original Message----- > > From: Kashyap Chamarthy [mailto:kcham...@redhat.com] > > Sent: 23 October 2015 12:37 > > To: Tim Bell <tim.b...@cern.ch> >

Re: [Openstack-operators] raw ephemeral disks and qcow2 images

On Fri, Oct 23, 2015 at 06:21:23AM +, Tim Bell wrote: > > On 22/10/15 20:01, "Marc Heckmann" wrote: > > >Hi, > > > >On Thu, 2015-10-22 at 08:17 -0700, Abel Lopez wrote: > >> I've actually looked for this for our RBD backed ephemeral instances, > >> but found the

[Openstack-operators] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

Background -- Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging mechanism that allows one to capture the current state of a Nova process/executable (e.g. `nova-compute`, `nova-api`, etc). The way to generate the error report is to supply the 'User-defined signal',

[openstack-dev] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

Background -- Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging mechanism that allows one to capture the current state of a Nova process/executable (e.g. `nova-compute`, `nova-api`, etc). The way to generate the error report is to supply the 'User-defined signal',

Re: [openstack-dev] [nova] live migration in Mitaka

On Fri, Oct 02, 2015 at 06:20:31AM +, Koniszewski, Pawel wrote: > > -Original Message- > > From: Mathieu Gagné [mailto:mga...@internap.com] > > Sent: Thursday, October 1, 2015 7:24 PM > > To: OpenStack Development Mailing List (not for usage questions) [. . .] > > >> I have taken the

Re: [openstack-dev] [nova] live migration in Mitaka

On Wed, Sep 30, 2015 at 11:25:12AM +, Murray, Paul (HP Cloud) wrote: > > > Please respond to this post if you have an interest in this and what > > you would like to see done. Include anything you are already > > getting on with so we get a clear picture. > > Thank you to those who replied

Re: [openstack-dev] [all][elections] PTL nomination period is now over

On Thu, Sep 17, 2015 at 05:09:04PM -0400, Nikhil Komawar wrote: [. . .] > > I think this is all superfluous however and we should simply encourage > > people to not wait until the last minute. Waiting to see who is > > running/what the field looks like isn't as important as standing up > > and

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote: On 06/24/2015 02:33 PM, Matt Riedemann wrote: [. . .] I agree completely. The nicely rendered feature docs which is a byproduct of the specs process in gerrit is a great part of it. So when someone is trying to use a new

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On Wed, Jun 24, 2015 at 04:09:16PM +0200, Kashyap Chamarthy wrote: On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote: On 06/24/2015 02:33 PM, Matt Riedemann wrote: [. . .] I agree completely. The nicely rendered feature docs which is a byproduct of the specs process

Re: [openstack-dev] [Nova] The unbearable lightness of specs

On Wed, Jun 24, 2015 at 10:02:27AM -0500, Matt Riedemann wrote: On 6/24/2015 9:09 AM, Kashyap Chamarthy wrote: On Wed, Jun 24, 2015 at 02:51:38PM +0100, Nikola Đipanov wrote: On 06/24/2015 02:33 PM, Matt Riedemann wrote: [. . .] This is one of the _baffling_ aspects -- that a so-called

Re: [openstack-dev] [Nova] Follow up actions from the Summit: please help

On Fri, Jun 05, 2015 at 10:47:31AM +0100, John Garbutt wrote: Hi, So in the interests of filling up your inbox yet further... We have lots of etherpads from the summit: https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Nova I have extracted all the action items here:

Re: [openstack-dev] [qa] Need volunteers for tempest bug triage

On Sat, May 30, 2015 at 03:52:02PM +0300, Yaroslav Lobankov wrote: Hi everyone, Is it possible for other people (not only core reviewers) to participate in bug triage? I would like to help in doing this. Absolutely. There's no such silly rule that only core reviwers can do bug triage. While

Re: [openstack-dev] [nova] Can we bump MIN_LIBVIRT_VERSION to 1.2.2 in Liberty?

On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote: The minimum required version of libvirt in the driver is 0.9.11 still [1]. We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno. The libvirt distro support matrix is here: [2] Can we safely assume the people

Re: [openstack-dev] [nova-docker] Status update

On Sat, May 09, 2015 at 04:55:47PM +, Adrian Otto wrote: I will also mention that it’s natural to be allergic to the idea of nested virtualization. We all know that creating multiple levels of hardware virtualization leads to bad performance outcomes. This seems to paint an overly bleak

Re: [openstack-dev] [all] cross project communication: periodic developer newsletter?

On Mon, May 04, 2015 at 07:22:24PM +, Nikhil Komawar wrote: This is a really nice idea. Idea is indeed nice, but I have to fully agree with all of what Theirry says. I feel the same, that we can offload some I personally don't feel it's about offloading to some hypothetical person

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

On Tue, Apr 21, 2015 at 02:58:57PM -0700, Joe Gordon wrote: On Fri, Apr 17, 2015 at 1:22 AM, Victor Stinner vstin...@redhat.com wrote: For the full list, see the wiki page: https://wiki.openstack.org/wiki/Python3#Core_OpenStack_projects Thanks for updating the wiki page that is a

Re: [openstack-dev] VM migration between two data centers

On Fri, Apr 17, 2015 at 04:05:20PM +0530, Abhishek Talwar/HYD/TCS wrote: Hi Folks, I have created two data centers and I am using OpenStack as the management platform for them. So now my question is it is possible to migrate VM instances from one data center to the other. Please ask such

Re: [openstack-dev] [Nova] Regarding deleting snapshot when instance is OFF

On Wed, Apr 08, 2015 at 11:31:40PM +0530, Deepak Shetty wrote: Hi, Cinder w/ GlusterFS backend is hitting the below error as part of test_volume_boot_pattern tempest testcase [Meta comment: Since main components that are triggering this errors are Cinder with GlusterFS, adding Cinder tag

Re: [openstack-dev] [nova] bug expiration

On Thu, Apr 02, 2015 at 11:32:44AM +0200, Thierry Carrez wrote: Sean Dague wrote: I just spent a chunk of the morning purging out some really old Incomplete bugs because about 9 months ago we disabled the auto expiration bit in launchpad -

Re: [openstack-dev] [devstack]Specific Juno version

On Wed, Mar 04, 2015 at 02:41:53PM +0200, Eduard Matei wrote: Hi Ihar, This is the error i see in c-vol screen: 2015-03-03 18:39:34.060 DEBUG taskflow.engines.action_engine.runner [req-87db2771-5c25-4c9b-a3bc-f7a504468315 4af0a30fe2c14deb9f9cf341a97daa9f 1fbab1e235ff414abf249c741fb3c6c9]

Re: [openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

On Tue, Feb 24, 2015 at 10:02:36PM -0800, Mark Atwood wrote: On Tue, Feb 24, 2015, at 04:28, Kashyap Chamarthy wrote: Along with the below, if push comes to shove, OpenStack Foundation could probably try a milder variant (obviously, not all activities can be categorized as 'critical path

  1   2   >