[openstack-dev] [nova] Reminder about stable/queens backports

I'm going through the proposed stable/queens backports and marking them as -Workflow if they are not fixing a regression introduced in queens itself or required for a queens-rc2 tag. If we have a need for a queens-rc2 tag then we can assess if any of these other backports should be included,

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

On Mon, 12 Feb 2018, Jay Pipes wrote: On 02/12/2018 10:27 AM, Eric Fried wrote: I'm interested. No date/time preference so far as long as it sticks to Monday/Tuesday. Same for me. Tuesday would be best for me as Monday is api-sig day. -- Chris Dent (⊙＿⊙')

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

On 02/12/2018 10:27 AM, Eric Fried wrote: I'm interested. No date/time preference so far as long as it sticks to Monday/Tuesday. Same for me. -jay __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

I'm interested. No date/time preference so far as long as it sticks to Monday/Tuesday. efried On 02/12/2018 09:13 AM, Zhipeng Huang wrote: > Hi Nova team, > > Cyborg will have ptg sessions on Mon and Tue from 2:00pm to 6:00pm, and > we would love to invite any of you guys who is interested in

[openstack-dev] [nova][cyborg]Dublin PTG Cyborg Nova Interaction Discussion

Hi Nova team, Cyborg will have ptg sessions on Mon and Tue from 2:00pm to 6:00pm, and we would love to invite any of you guys who is interested in nova-cyborg interaction to join the discussion. The discussion will mainly focus on: (1) Cyborg team recap on the resource provider features that are

[openstack-dev] [nova] Regression bug for boot from volume with IsolatedHostsFilter

I triaged this bug a couple of weeks ago: https://bugs.launchpad.net/nova/+bug/1746483 It looks like it's been regressed since Mitaka when that filter started using the RequestSpec object rather than legacy filter_properties dict. Looking a bit deeper though, it looks like this filter never

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

+1 2018-02-09 23:01 GMT+08:00 Matt Riedemann : > I'd like to add Takashi to the python-novaclient core team. > > python-novaclient doesn't get a ton of activity or review, but Takashi has > been a solid reviewer and contributor to that project for quite awhile now: > >

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

On Fri, Feb 9, 2018 at 4:01 PM, Matt Riedemann wrote: I'd like to add Takashi to the python-novaclient core team. python-novaclient doesn't get a ton of activity or review, but Takashi has been a solid reviewer and contributor to that project for quite awhile now:

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

+1 2018年2月9日(金) 8:09 Stephen Finucane : > On Fri, 2018-02-09 at 09:01 -0600, Matt Riedemann wrote: > > I'd like to add Takashi to the python-novaclient core team. > > > > python-novaclient doesn't get a ton of activity or review, but Takashi > > has been a solid reviewer

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

On Fri, 2018-02-09 at 09:01 -0600, Matt Riedemann wrote: > I'd like to add Takashi to the python-novaclient core team. > > python-novaclient doesn't get a ton of activity or review, but Takashi > has been a solid reviewer and contributor to that project for quite > awhile now: > >

Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

+1, no objections so far. On Fri, Feb 9, 2018 at 4:01 PM, Matt Riedemann wrote: > I'd like to add Takashi to the python-novaclient core team. > > python-novaclient doesn't get a ton of activity or review, but Takashi has > been a solid reviewer and contributor to that

[openstack-dev] [nova] [placement] resource providers update 18-06

Resource provider 18-06 is here. # Most Important RC1 was cut last night, so we shouldn't be merging any new features now, just bug fixes. Which, of course, means finding and fixing bugs is the thing to do. In the gaps where that's not happening, planning for Rocky is a useful thing to be

[openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core

I'd like to add Takashi to the python-novaclient core team. python-novaclient doesn't get a ton of activity or review, but Takashi has been a solid reviewer and contributor to that project for quite awhile now: http://stackalytics.com/report/contribution/python-novaclient/180 He's always

[openstack-dev] [nova] nova 17.0.0.0rc1 (queens)

Hello everyone, A new release candidate for nova for the end of the Queens cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally

Re: [openstack-dev] [nova] Notification update week 6

On Tue, Feb 6, 2018 at 7:04 PM, Matt Riedemann wrote: On 2/5/2018 9:32 AM, Balázs Gibizer wrote: Introduce instance.lock and instance.unlock notifications - A specless bp has been proposed to the Rocky cycle

Re: [openstack-dev] [nova] Notification update week 6

On 2/5/2018 9:32 AM, Balázs Gibizer wrote: Introduce instance.lock and instance.unlock notifications - A specless bp has been proposed to the Rocky cycle

Re: [openstack-dev] [nova] Should we get auth from context for Neutron endpoint?

Zheng 先生- I *think* you're right that 'network' should be included in [2]. I can't think of any reason it shouldn't be. Does that fix the problem by itself? I believe the Neutron API code is already getting its auth from context... sometimes [5]. If you want to make sure it's

[openstack-dev] [nova] Should we get auth from context for Neutron endpoint?

Hi Nova, While doing some test with my newly deployed devstack env today, it turns out that the default devstack deployment cannot cleanup networks after the retry attempt exceeded. This is because in the deployment with super-conductor and cell-conductor, the retry and cleanup logic is in

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Given the size and detail of this thread, I've tried to summarize the problems and possible solutions/workarounds in this etherpad: https://etherpad.openstack.org/p/nova-aggregate-filter-allocation-ratio-snafu For those working on this, please check that what I have written down is correct

[openstack-dev] [nova] Notification update week 6

Hi, Here is the status update / focus settings mail for w6. Bugs No new bugs and the below bug status is the same as last week. [High] https://bugs.launchpad.net/nova/+bug/1737201 TypeError when sending notification during attach_interface Fix merged to master. Backports have been

[openstack-dev] [nova] [placement] resource providers update 18-05

Here's resource provider and placement update 18-05. 18-04 was skipped on account of illness. # Most Important Feature freeze has come and gone, RC1 is next week. This means that finding bugs and, where relevant, reporting them with a tag of 'queens-rc-potential' is top priority. The PTG is

Re: [openstack-dev] [nova] Requesting eyes on fix for bug 1686703

On 31 January 2018 at 16:32, Matt Riedemann wrote: > On 1/31/2018 7:30 AM, Matthew Booth wrote: > >> Could I please have some eyes on this bugfix: >> https://review.openstack.org/#/c/462521/ . I addressed an issue raised >> in August 2017, and it's had no negative feedback

[openstack-dev] [nova] PTL candidacy

Hello Stackers, I would like to announce my candidacy for Nova PTL in the Rocky cycle. I have been a core reviewer on Nova since May 2015 and have been working with OpenStack since mid 2012 (ancient times!) and you may know me on IRC as melwitt. I have been both a user and a developer on

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/2018 11:14 PM, Hanxi Liu wrote: Can I understand it as a trend that versioned notifications will replace unversioned notifications even though versioned notifications may have the only consumer for long time? The long-term goal in nova is to eventually have parity between the

Re: [openstack-dev] [nova][ironic] Tagging newton EOL

On 1/30/2018 10:17 PM, Tony Breeds wrote: Hi All, When we tagged newton EOL in October there were in-flight reviews for nova and ironic that needed to land before we could EOL them. That work completed but I dropped the ball. So can we tag those last 2 repos? As in October a member of

Re: [openstack-dev] [nova] Requesting eyes on fix for bug 1686703

On 1/31/2018 7:30 AM, Matthew Booth wrote: Could I please have some eyes on this bugfix: https://review.openstack.org/#/c/462521/ . I addressed an issue raised in August 2017, and it's had no negative feedback since. It would be good to get this one finished. First, I'd like to avoid setting

[openstack-dev] [nova] Requesting eyes on fix for bug 1686703

Could I please have some eyes on this bugfix: https://review.openstack.org/#/c/462521/ . I addressed an issue raised in August 2017, and it's had no negative feedback since. It would be good to get this one finished. Thanks, Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone:

Re: [openstack-dev] [nova][ironic] Tagging newton EOL

Hi! Ironic is ready for newton EOL. On 01/31/2018 05:17 AM, Tony Breeds wrote: Hi All, When we tagged newton EOL in October there were in-flight reviews for nova and ironic that needed to land before we could EOL them. That work completed but I dropped the ball. So can we tag those last

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On Wed, Jan 31, 2018 at 1:17 AM, Matt Riedemann wrote: > On 1/30/2018 9:37 AM, Mathieu Gagné wrote: > >> So I just discovered this documentation. It's awesome! Great job to >> all the ones involved! >> Now I wish we had the same in all projects. =) >> > > Maybe it's worth

[openstack-dev] [nova][ironic] Tagging newton EOL

Hi All, When we tagged newton EOL in October there were in-flight reviews for nova and ironic that needed to land before we could EOL them. That work completed but I dropped the ball. So can we tag those last 2 repos? As in October a member of the infra team needs to do this *or* I can be

Re: [openstack-dev] [nova][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

On 1/30/2018 1:04 PM, Chris Friesen wrote: Is there a plan going forward to ensure that python-novaclient and OSC are on the same page as far as deprecating CLIs and API bindings? There is no official plan, no. The 10.0.0 novaclient release came out late. If there was more lead time, or if I

Re: [openstack-dev] [nova][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

On 01/30/2018 09:15 AM, Matt Riedemann wrote: The 10.0.0 release of python-novaclient dropped some deprecated CLIs and python API bindings for the server actions to add/remove fixed and floating IPs: https://docs.openstack.org/releasenotes/python-novaclient/queens.html#id2

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/2018 11:17 AM, Matt Riedemann wrote: Maybe it's worth putting something into the community goals etherpad: https://etherpad.openstack.org/p/community-goals I added the "Convert from legacy to versioned notifications" entry to keep the idea for the future. -- Thanks, Matt

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/18, 11:17 AM, "Matt Riedemann" wrote: On 1/30/2018 9:37 AM, Mathieu Gagné wrote: > So I just discovered this documentation. It's awesome! Great job to > all the ones involved! > Now I wish we had the same in all projects. =) Maybe it's worth

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/2018 9:37 AM, Mathieu Gagné wrote: So I just discovered this documentation. It's awesome! Great job to all the ones involved! Now I wish we had the same in all projects. =) Maybe it's worth putting something into the community goals etherpad:

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 2018-01-30 10:19 AM, Matt Riedemann wrote: > Gibi's burndown chart is here to see what's remaining: > > http://burndown.peermore.com/nova-notification/ this answer far exceeded my expectations :) thanks! -- gord __

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On Tue, Jan 30, 2018 at 10:19 AM, Matt Riedemann wrote: > > Gibi's burndown chart is here to see what's remaining: > > http://burndown.peermore.com/nova-notification/ > > And this is the list of what's already done: > >

Re: [openstack-dev] [nova][ceilometer] versioned notifications coverage

On 1/30/2018 9:01 AM, gordon chung wrote: hi, we've had an open item to consume versioned notifications in ceilometer. the question that remains is: do all unversioned notifications have a versioned version or are there still some items missing? the blocker for us is that we can't consume both

[openstack-dev] [nova][osc] How to deal with add/remove fixed/floating CLIs after novaclient 10.0.0?

The 10.0.0 release of python-novaclient dropped some deprecated CLIs and python API bindings for the server actions to add/remove fixed and floating IPs: https://docs.openstack.org/releasenotes/python-novaclient/queens.html#id2 python-openstackclient was using some of those python API

[openstack-dev] [nova][ceilometer] versioned notifications coverage

hi, we've had an open item to consume versioned notifications in ceilometer. the question that remains is: do all unversioned notifications have a versioned version or are there still some items missing? the blocker for us is that we can't consume both as then we'd end up duplicating data but

Re: [openstack-dev] [nova]Nova rescue inject pasword failed

Thank you,Mathieu.Do you know how to use metadata RESTful service to inject password? -- Original -- From: "Mathieu Gagné"; Date: 2018年1月30日(星期二) 凌晨3:05 To: "OpenStack Developmen"; Subject: Re: [openstack-dev] [nova]Nova rescue inject pasw

Re: [openstack-dev] [nova]Nova rescue inject pasword failed

On Mon, Jan 29, 2018 at 4:57 AM, Matthew Booth wrote: > On 29 January 2018 at 09:27, 李杰 wrote: >> >> Hi,all: >> I want to access to my instance under rescue state using >> temporary password which nova rescue gave me.But this password doesn't

Re: [openstack-dev] [nova][placement] Re: VMWare's resource pool / cluster and nested resource providers

We had some lively discussion in #openstack-nova today, which I'll try to summarize here. First of all, the hierarchy: controller (n-cond) / \ cluster/n-cpu cluster/n-cpu / \ / \ res. poolres. pool

[openstack-dev] [nova] Notification update week 5

Hi, Here is the status update / focus settings mail for w5. Bugs [High] https://bugs.launchpad.net/nova/+bug/1742962 nova functional test does not triggered on notification sample only changes Fix merged to master, backports are on the gate. When backport lands we can merge the removal

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

On Fri, Jan 26, 2018 at 6:57 PM, James E. Blair wrote: Balázs Gibizer writes: Hi, I'm getting more and more confused how the zuul job hierarchy works or is supposed to work. Hi! First, you (or others) may or may not have seen this

Re: [openstack-dev] [nova]Nova rescue inject pasword failed

-- From: "Matthew Booth"<mbo...@redhat.com>; Date: Mon, Jan 29, 2018 05:57 PM To: "OpenStack Developmen"<openstack-dev@lists.openstack.org>; Subject: Re: [openstack-dev] [nova]Nova rescue inject pasword failed On 29 January 2018 at 09:27, 李杰 &l

Re: [openstack-dev] [nova]Nova rescue inject pasword failed

On 29 January 2018 at 09:27, 李杰 wrote: > Hi,all: > I want to access to my instance under rescue state using > temporary password which nova rescue gave me.But this password doesn't > work. Can I ask how this password is injected to instance? I can't find any >

[openstack-dev] [nova]Nova rescue inject pasword failed

Hi,all: I want to access to my instance under rescue state using temporary password which nova rescue gave me.But this password doesn't work. Can I ask how this password is injected to instance? I can't find any specification how is it done.I saw the code about rescue,But it displays

[openstack-dev] [nova][placement] Re: VMWare's resource pool / cluster and nested resource providers

Rado-     [+dev ML.  We're getting pretty general here; maybe others will get some use out of this.] > is there a way to make the scheduler allocate only from one specific RP     "...one specific RP" - is that Resource Provider or Resource Pool?     And are we talking about scheduling an

Re: [openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

Balázs Gibizer writes: > Hi, > > I'm getting more and more confused how the zuul job hierarchy works or > is supposed to work. Hi! First, you (or others) may or may not have seen this already -- some of it didn't exist when we first rolled out v3, and some of it

[openstack-dev] [nova][neutron][infra] zuul job definitions overrides and the irrelevant-file attribute

Hi, I'm getting more and more confused how the zuul job hierarchy works or is supposed to work. First there was a bug in nova that some functional tests are not triggered although the job (re-)definition in the nova part of the project-config should not prevent it to run [1]. There we

[openstack-dev] [nova] q-3 tag and gate status

At this point in the day, I'm going to push the q-3 tag. We have quite a few things approved but not yet merged (some for over 20 hours in the gate now). The latest list of stuff that's approved is in the etherpad here: https://etherpad.openstack.org/p/nova-queens-blueprint-status I don't

Re: [openstack-dev] [nova][thirdparty][CI] Nova IBM zKVM CI broken

CI should be back online now, tests are running again… Let’s see if the tests succeed.. The issue was, that for some reason a new pip package ‘python-pcre’ got installed. But the build failed, as the build dependency 'libpcre3-dev’ as not satisfied. Now the package 'libpcre3-dev' is part of

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On 24 January 2018 at 22:57, Matt Riedemann wrote: > On 1/22/2018 8:22 AM, Lee Yarwood wrote: > >> Hello, >> >> With M3 and FF rapidly approaching this week I wanted to post a brief >> overview of the QEMU native LUKS series. >> >> The full series is available on the

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 >

[openstack-dev] [nova][thirdparty][CI] Nova IBM zKVM CI broken

Hi, the Nova IBM zKVM CI is currently producing invalid builds. Please ignore the -1 results for now. I’m working on fixing it. Will let you know once it’s working fine again. Thanks! --- Andreas Scheuring (andreas_s)

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

2018-01-22 15:09 GMT-08:00 Matt Riedemann : > On 1/15/2018 11:04 AM, Kendall Nelson wrote: >> >> Election details: https://governance.openstack.org/election/ >> >> Please read the stipulations and timelines for candidates and electorate >> contained in this governance

[openstack-dev] [nova][neutron] Extend instance IP filter for floating IP

Hi all, Nova currently allows us to filter instances by fixed IP address(es). This feature is known to be useful in an operational scenario that cloud administrators detect abnormal traffic in an IP address and want to trace down to the instance that this IP address belongs to. This feature

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On 1/22/2018 8:22 AM, Lee Yarwood wrote: Hello, With M3 and FF rapidly approaching this week I wanted to post a brief overview of the QEMU native LUKS series. The full series is available on the following topic, I'll go into more detail on each of the changes below:

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

On 01/22/2018 06:09 PM, Matt Riedemann wrote: On 1/15/2018 11:04 AM, Kendall Nelson wrote: Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Be aware, in the PTL

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On 23-01-18 13:44:49, Lee Yarwood wrote: > A breif progress update in-line below. > > On 22-01-18 14:22:12, Lee Yarwood wrote: > > Hello, > > > > With M3 and FF rapidly approaching this week I wanted to post a brief > > overview of the QEMU native LUKS series. > > > > The full series is

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On 23-01-18 16:52:30, Corey Bryant wrote: > On Tue, Jan 23, 2018 at 8:44 AM, Lee Yarwood wrote: >> grenade-dsvm-neutron-multinode-live-migration is currently failing due >> to our use of the Ocata UCA on stable/pike leading to the following >> issue with the libvirt 2.5.0

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

On Tue, Jan 23, 2018 at 8:44 AM, Lee Yarwood wrote: > A breif progress update in-line below. > > On 22-01-18 14:22:12, Lee Yarwood wrote: > > Hello, > > > > With M3 and FF rapidly approaching this week I wanted to post a brief > > overview of the QEMU native LUKS series. > >

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

On Tue, Jan 23, 2018 at 12:09 AM, Matt Riedemann wrote: > On 1/15/2018 11:04 AM, Kendall Nelson wrote: > >> Election details: https://governance.openstack.org/election/ >> >> Please read the stipulations and timelines for candidates and electorate >> contained in this

Re: [openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

A breif progress update in-line below. On 22-01-18 14:22:12, Lee Yarwood wrote: > Hello, > > With M3 and FF rapidly approaching this week I wanted to post a brief > overview of the QEMU native LUKS series. > > The full series is available on the following topic, I'll go into more > detail on

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

On Tue, Jan 23, 2018 at 12:09 AM, Matt Riedemann wrote: On 1/15/2018 11:04 AM, Kendall Nelson wrote: Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance

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

Thanks Matt, for patiently reviewing our patches, helping newbies like me integrate well into the Nova team and for being an amazing PTL. Best Regards, Surya. On Tue, Jan 23, 2018 at 11:00 AM, John Garbutt wrote: > On 23 January 2018 at 04:04, Ed Leafe

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

On 23 January 2018 at 04:04, Ed Leafe wrote: > On Jan 22, 2018, at 5:09 PM, 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

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

On Mon, 22 Jan 2018, Ed Leafe wrote: I still don't understand how anyone could do what you have done over these past two years and not a) had a stress-induced heart attack or b) gotten divorced. Indeed, Matt has been an amazing PTL. Thank you Matt for all your hard work. The quality of your

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

Thanks for all the help in these cycles :) On Tue, Jan 23, 2018 at 5:34 PM, Yikun Jiang wrote: > Matt, Thanks for your all works. > As a beginner of Nova upstream player, really appreciate your patient > review and warm help. : ) > > Regards, > Yikun >

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

Matt, Thanks for your all works. As a beginner of Nova upstream player, really appreciate your patient review and warm help. : ) Regards, Yikun Jiang Yikun（Kero） Mail: yikunk...@gmail.com 2018-01-23 7:09 GMT+08:00 Matt Riedemann : >

[openstack-dev] [nova] API reference verification for servers APIs (parameter and example)

Hi, Nova developers. There was work verifying the Nova compute API Reference (*1, *2, *3, *4) before. But the verification has not been completed yet in "Servers" APIs (creating, updating, deleting a server, listing servers, etc.). *1: Convert API Reference to RST and host it in the Nova tree

Re: [openstack-dev] [nova] Add scenario tests based on multiple cells environment

Hello This time we plan to post multiple patches. In order to put them together, we created BP I posted a test verifying the operation of the existing Nova API in a multi-cell environment. Please review. https://review.openstack.org/#/c/534116/ -- Tomotaka Nakanishi E-Mail :

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

On Jan 22, 2018, at 5:09 PM, 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] [nova] PTL Election Season

Matt, thanks for your leading and help over the past years! Your obsessive paperwork is really helpful and I appreciate for that. 2018-01-23 7:09 GMT+08:00 Matt Riedemann : > On 1/15/2018 11:04 AM, Kendall Nelson wrote: > >> Election details:

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

On Tue, Jan 23, 2018 at 4:39 AM, Matt Riedemann wrote: > On 1/15/2018 11:04 AM, Kendall Nelson wrote: >> >> Election details: https://governance.openstack.org/election/ >> >> Please read the stipulations and timelines for candidates and electorate >> contained in this

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

Matt, thank you for all you have done for Nova. It's a good journey to work with you in past 7 years. And I'm looking forward to meeting you in next summit. On 23/01/18 12:09, Matt Riedemann wrote: > On 1/15/2018 11:04 AM, Kendall Nelson wrote: >> Election details:

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

Park, Haidian District, Beijing 100193, PRC From: Matt Riedemann <mriede...@gmail.com> To: openstack-dev@lists.openstack.org Date: 01/23/2018 07:10 AM Subject: Re: [openstack-dev] [nova] PTL Election Season On 1/15/2018 11:04 AM, Kendall Nelson wrote: > Election detai

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

> On Jan 22, 2018, at 6:46 PM, Jay S Bryant wrote: > > > >> On 1/22/2018 5:09 PM, Matt Riedemann wrote: >>> On 1/15/2018 11:04 AM, Kendall Nelson wrote: >>> Election details: https://governance.openstack.org/election/ >>> >>> Please read the stipulations and timelines

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

On 1/22/2018 5:09 PM, Matt Riedemann wrote: On 1/15/2018 11:04 AM, Kendall Nelson wrote: Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Be aware, in the PTL

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

On 1/15/2018 11:04 AM, Kendall Nelson wrote: Election details: https://governance.openstack.org/election/ Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Be aware, in the PTL elections if the program only has one candidate,

[openstack-dev] [nova] Native QEMU LUKS decryption review overview ahead of FF

Hello, With M3 and FF rapidly approaching this week I wanted to post a brief overview of the QEMU native LUKS series. The full series is available on the following topic, I'll go into more detail on each of the changes below:

[openstack-dev] [nova] Notification update week 4

Hi, Here is the status update / focus settings mail for w4. Bugs [High] https://bugs.launchpad.net/nova/+bug/1742962 nova functional test does not triggered on notification sample only changes During the zuul v3 migration the project-config generated based on the zuul v2 jobs. It contained

Re: [openstack-dev] [nova] Local disk serial numbers series for reviewers: update 9th Jan

On 9 January 2018 at 15:28, Matthew Booth wrote: > In summary, the patch series is here: > > https://review.openstack.org/#/q/status:open+project:opensta > ck/nova+branch:master+topic:bp/local-disk-serial-numbers > > The bottom 3 patches, which add BDM.uuid have landed. The

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/19/2018 10:21 AM, Chris Friesen wrote: On 01/18/2018 02:54 PM, Mathieu Gagné wrote: We use this feature to segregate capacity/hosts based on CPU allocation ratio using aggregates. This is because we have different offers/flavors based on those allocation ratios. This is part of our

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Hi Chris, On Fri, Jan 19, 2018 at 10:21 AM, Chris Friesen wrote: > > The existing mechanisms to control aggregate membership will still work, so > the remaining issue is how to control the allocation ratios. > > What about implementing a new HTTP API call (as a local

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/18/2018 02:54 PM, Mathieu Gagné wrote: We use this feature to segregate capacity/hosts based on CPU allocation ratio using aggregates. This is because we have different offers/flavors based on those allocation ratios. This is part of our business model. A flavor extra_specs is use to

Re: [openstack-dev] [nova] [placement] resource providers update 18-03

> Earlier in the week I did some exercising by humans and was confused > by the state of traits handling on /allocation_candidates (it could be > the current state is the expected state but the code didn't make that > clear) so I made a bug on it make sure that confusion didn't get forgotten: > >

[openstack-dev] [nova] [placement] resource providers update 18-03

Here's resource provider and placement update 18-03. I'm travelling so this version may be a bit abridged. # Most Important This remains mostly the same, getting alternate hosts all the way in and finishing up nested resource provider support (as ProviderTree on the nova side and support for

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On Thu, Jan 18, 2018 at 5:19 PM, Jay Pipes wrote: > On 01/18/2018 03:54 PM, Mathieu Gagné wrote: >> >> Hi, >> >> On Tue, Jan 16, 2018 at 4:24 PM, melanie witt wrote: >>> >>> Hello Stackers, >>> >>> This is a heads up to any of you using the

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/18/2018 03:54 PM, Mathieu Gagné wrote: Hi, On Tue, Jan 16, 2018 at 4:24 PM, melanie witt wrote: Hello Stackers, This is a heads up to any of you using the AggregateCoreFilter, AggregateRamFilter, and/or AggregateDiskFilter in the filter scheduler. These filters have

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Hi, On Tue, Jan 16, 2018 at 4:24 PM, melanie witt wrote: > Hello Stackers, > > This is a heads up to any of you using the AggregateCoreFilter, > AggregateRamFilter, and/or AggregateDiskFilter in the filter scheduler. > These filters have effectively allowed operators to set

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/18/2018 03:06 PM, Logan V. wrote: We have used aggregate based scheduler filters since deploying our cloud in Kilo. This explains the unpredictable scheduling we have seen since upgrading to Ocata. Before this post, was there some indication I missed that these filters can no longer be

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

We have used aggregate based scheduler filters since deploying our cloud in Kilo. This explains the unpredictable scheduling we have seen since upgrading to Ocata. Before this post, was there some indication I missed that these filters can no longer be used? Even now reading the Ocata release

[openstack-dev] [nova] about rebuild instance booted from volume

Hi,all This is the spec about rebuild a instance booted from volume, anyone who is interested in booted from volume can help to review this. Any suggestion is welcome. The link is here. Re:the rebuild spec:https://review.openstack.org/#/c/532407/

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On Wed, Jan 17, 2018 at 2:22 PM, Jay Pipes wrote: > On 01/16/2018 08:19 PM, Zhenyu Zheng wrote: > >> Thanks for the info, so it seems we are not going to implement aggregate >> overcommit ratio in placement at least in the near future? >> > > As @edleafe alluded to, we will

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On 01/16/2018 08:19 PM, Zhenyu Zheng wrote: Thanks for the info, so it seems we are not going to implement aggregate overcommit ratio in placement at least in the near future? As @edleafe alluded to, we will not be adding functionality to the placement service to associate an overcommit ratio

[openstack-dev] [Nova][Ironic][API] Service Management API Design

Hi Nova Developers, I am working on adding a service management API in Ironic [1][2]. This spec adds a new API /conductors to list, enable/disable an ironic-conductor service. I am struggling to understand the difference between shutting down a service manually and disabling it. So my question

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

On Jan 16, 2018, at 7:21 PM, Zhenyu Zheng wrote: > Thanks for the info, so it seems we are not going to implement aggregate > overcommit ratio in placement at least in the near future? I would go so far as to say that we are not going to implement aggregate

Re: [openstack-dev] [nova] heads up to users of Aggregate[Core|Ram|Disk]Filter: behavior change in >= Ocata

Thanks for the info, so it seems we are not going to implement aggregate overcommit ratio in placement at least in the near future? On Wed, Jan 17, 2018 at 9:19 AM, Zhenyu Zheng wrote: > Thanks for the info, so it seems we are not going to implement aggregate >

<    7   8   9   10   11   12   13   14   15   16   >