Re: [openstack-dev] [nova] Forum topics brainstorming

2017-09-28 23:45 GMT+02:00 Matt Riedemann : > On 9/21/2017 4:01 PM, Matt Riedemann wrote: > >> So this shouldn't be news now that I've read back through a few emails in >> the mailing list (I've been distracted with the Pike release, PTG planning, >> etc) [1][2][3] but we have until Sept 29 to com

Re: [openstack-dev] vGPUs support for Nova - Implementation

On Fri, Sep 29, 2017 at 2:32 AM, Dan Smith wrote: > In this serie of patches we are generalizing the PCI framework to >>> handle MDEV devices. We arguing it's a lot of patches but most of them >>> are small and the logic behind is basically to make it understand two >>> new fields MDEV_PF and MDE

Re: [openstack-dev] [Blazar] Team mascot idea

FWIW, the original name for Blazar was "Climate" so what about a weather frog ? :-) -Sylvain 2017-10-11 7:29 GMT+02:00 Masahito MUROI : > Hi Blazar folks, > > As we discussed the topic in the last meeting, we're gathering an idea for > the project mascot[1]. > > Current ideas are following fours

Re: [openstack-dev] [ironic] ironic and traits

On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried wrote: > I agree with Sean. In general terms: > > * A resource provider should be marked with a trait if that feature > * Can be turned on or off (whether it's currently on or not); or > * Is always on and can't ever be turned off. > No, traits ar

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

On Thu, Dec 14, 2017 at 10:09 AM, Thierry Carrez wrote: > Matt Riedemann wrote: > > On 12/13/2017 4:15 PM, Thierry Carrez wrote: > >> Based on several discussions I had with developers working part-time on > >> OpenStack at various events lately, it sounded like slowing down our > >> pace could b

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 not be adding function

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 documentation. >>

Re: [openstack-dev] [nova] [placement] unresolved topics in resource providers/placement api

Le 28/07/2016 15:57, Chris Dent a écrit : I've been reviewing my notes from the mid-cycle and discussions leading up to it and realized I have a few unresolved or open topics that I hope discussion here can help resolve: # fairly straightforward things * At what stage in the game (of the pla

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

Le 15/08/2016 22:59, Andrew Laski a écrit : On Mon, Aug 15, 2016, at 10:33 AM, Jay Pipes wrote: On 08/15/2016 09:27 AM, Andrew Laski wrote: Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute hosts expose "

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

Le 25/08/2016 16:19, Andrew Laski a écrit : Cross posting to gather some operator feedback. There have been a couple of contentious patches gathering attention recently about how to handle the case where a block device mapping supersedes flavor information. Before moving forward on either of t

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

Le 26/08/2016 12:33, Chris Dent a écrit : On Thu, 25 Aug 2016, Sylvain Bauza wrote: Of course, long-term, we could try to see how to have composite flavors for helping users to not create a whole handful of flavors for quite the same user requests, but that would still be flavors (or the

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

Le 29/08/2016 13:25, Jay Pipes a écrit : On 08/26/2016 09:20 AM, Ed Leafe wrote: On Aug 25, 2016, at 3:19 PM, Andrew Laski wrote: One other thing to note is that while a flavor constrains how much local disk is used it does not constrain volume size at all. So a user can specify an ephemer

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

Le 29/08/2016 14:20, Jay Pipes a écrit : On 08/29/2016 05:11 AM, Sylvain Bauza wrote: Le 29/08/2016 13:25, Jay Pipes a écrit : On 08/26/2016 09:20 AM, Ed Leafe wrote: On Aug 25, 2016, at 3:19 PM, Andrew Laski wrote: One other thing to note is that while a flavor constrains how much local

Re: [openstack-dev] [Nova] Reconciling flavors and block device mappings

Le 29/08/2016 14:43, Andrew Laski a écrit : On Mon, Aug 29, 2016, at 08:20 AM, Jay Pipes wrote: On 08/29/2016 05:11 AM, Sylvain Bauza wrote: Le 29/08/2016 13:25, Jay Pipes a écrit : On 08/26/2016 09:20 AM, Ed Leafe wrote: On Aug 25, 2016, at 3:19 PM, Andrew Laski wrote: One other thing

Re: [openstack-dev] [nova] Next steps for resource providers work

Le 31/08/2016 13:08, Jay Pipes a écrit : On 08/29/2016 12:40 PM, Matt Riedemann wrote: I've been out for a week and not very involved in the resource providers work, but after talking about the various changes up in the air at the moment a bunch of us thought it would be helpful to lay out nex

Re: [openstack-dev] Seeking Mobile Beta Testers

Le 02/09/2016 19:57, Jimmy McArthur a écrit : We're looking for a handful of community members to test our updated OpenStack Summit mobile Apps. If you're interested, shoot me a note, along with iOS/Android preference, and we'll get you set up. Count me in. The previous experience in Austi

Re: [openstack-dev] [nova] resignation from bug czar role

Le 05/09/2016 13:19, Markus Zoeller a écrit : TL;DR: bug czar role for Nova is vacant from now on After doing bug triage for ~1 year, which was quiet interesting, it's time for me to move to different topics. My tasks within the company internal team are shifting too. Unfortunately less Nova

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

Le 07/09/2016 10:50, Kashyap Chamarthy a écrit : 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 m

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 project for quite awhile no

Re: [openstack-dev] [nova] Rocky spec review day

On Wed, Mar 21, 2018 at 2:12 PM, Eric Fried wrote: > +1 for the-earlier-the-better, for the additional reason that, if we > don't finish, we can do another one in time for spec freeze. > > +1 for Wed 27th March. > And I, for one, wouldn't be offended if we could "officially start > development

Re: [openstack-dev] [nova] Proposing Eric Fried for nova-core

+1 On Tue, Mar 27, 2018 at 4:00 AM, melanie witt wrote: > Howdy everyone, > > I'd like to propose that we add Eric Fried to the nova-core team. > > Eric has been instrumental to the placement effort with his work on nested > resource providers and has been actively contributing to many other are

Re: [openstack-dev] [nova] [placement] placement update 18-14

On Fri, Apr 6, 2018 at 2:54 PM, Chris Dent wrote: > > This is "contract" style update. New stuff will not be added to the > lists. > > # Most Important > > There doesn't appear to be anything new with regard to most > important. That which was important remains important. At the > scheduler team

Re: [openstack-dev] [placement][nova] Decision time on granular request groups for like resources

2018-04-19 10:38 GMT+02:00 Balázs Gibizer : > > > On Thu, Apr 19, 2018 at 12:45 AM, Eric Fried wrote: > >> I have a feeling we're just going to go back and forth on this, as we >>> have for weeks now, and not reach any conclusion that is satisfactory to >>> everyone. And we'll delay, yet again

Re: [openstack-dev] [nova][placement] Trying to summarize bp/glance-image-traits scheduling alternatives for rebuild

Sorry folks for the late reply, I'll try to also weigh in the Gerrit change. On Tue, Apr 24, 2018 at 2:55 PM, Jay Pipes wrote: > On 04/23/2018 05:51 PM, Arvind N wrote: > >> Thanks for the detailed options Matt/eric/jay. >> >> Just few of my thoughts, >> >> For #1, we can make the explanation ve

Re: [openstack-dev] [cyborg] [nova] Cyborg quotas

Le ven. 18 mai 2018 à 13:59, Nadathur, Sundar a écrit : > Hi Matt, > On 5/17/2018 3:18 PM, Matt Riedemann wrote: > > On 5/17/2018 3:36 PM, Nadathur, Sundar wrote: > > This applies only to the resources that Nova handles, IIUC, which does not > handle accelerators. The generic method that Alex tal

Re: [openstack-dev] [Openstack-operators] [nova] Need some feedback on the proposed heal_allocations CLI

On Fri, May 25, 2018 at 12:19 AM, Matt Riedemann wrote: > I've written a nova-manage placement heal_allocations CLI [1] which was a > TODO from the PTG in Dublin as a step toward getting existing > CachingScheduler users to roll off that (which is deprecated). > > During the CERN cells v1 upgrade

[openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Hi, I already told about that in a separate thread, but let's put it here too for more visibility. tl;dr: I suspect existing allocations are being lost when we upgrade a compute service from Queens to Rocky, if those allocations are made against inventories that are now provided by a child Resour

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

ation again for the created new child after > upgrading? > > I wonder if we should keep the existing inventory in the root RP, and somehow just reserve the left resources (so Placement wouldn't pass that root RP for queries, but would still have allocations). But then, where and how to d

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

2018-05-29 11:01 GMT+02:00 Balázs Gibizer : > > > On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza wrote: > >> >> >> On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA < >> nakamura.tets...@lab.ntt.co.jp> wrote >> >> > In that situation, s

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

Le mar. 29 mai 2018 à 11:02, Balázs Gibizer a écrit : > > > On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza > wrote: > > > > > > On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA > > wrote > > > >> > In that situation, say for example with

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer wrote: > > > On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza wrote: > >> >> >> Le mar. 29 mai 2018 à 11:02, Balázs Gibizer >> a écrit : >> >>> >>> >>> On Tue, May 29, 2018 a

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

On Wed, May 30, 2018 at 1:33 AM, Nadathur, Sundar wrote: > Hi all, >The Cyborg/Nova scheduling spec [1] details what traits will be applied > to the resource providers that represent devices like GPUs. Some of the > traits referred to vendor names. I got feedback that traits must not refer >

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Wed, May 30, 2018 at 1:06 PM, Balázs Gibizer wrote: > > > On Tue, May 29, 2018 at 3:12 PM, Sylvain Bauza wrote: > >> >> >> On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer < >> balazs.gibi...@ericsson.com> wrote: >> >>> >>

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 3:54 PM, Eric Fried wrote: > This seems reasonable, but... > > On 05/31/2018 04:34 AM, Balázs Gibizer wrote: > > > > > > On Thu, May 31, 2018 at 11:10 AM, Sylvain Bauza > wrote: > >>> > >> > >> After considerin

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 4:34 PM, Jay Pipes wrote: > On 05/29/2018 09:12 AM, Sylvain Bauza wrote: > >> We could keep the old inventory in the root RP for the previous vGPU type >> already supported in Queens and just add other inventories for other vGPU >> types now suppor

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 5:00 PM, Jay Pipes wrote: > On 05/31/2018 05:10 AM, Sylvain Bauza wrote: > >> After considering the whole approach, discussing with a couple of folks >> over IRC, here is what I feel the best approach for a seamless upgrade : >> - VGPU inventory

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 7:09 PM, Dan Smith wrote: > > My feeling is that we should not attempt to "migrate" any allocations > > or inventories between root or child providers within a compute node, > > period. > > While I agree this is the simplest approach, it does put a lot of > responsibility

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 7:44 PM, Chris Dent wrote: > On Thu, 31 May 2018, Dan Smith wrote: > > I kinda think we need to either: >> >> 1. Make everything perform the pivot on compute node start (which can be >> re-used by a CLI tool for the offline case) >> > > This sounds effectively like: vali

Re: [openstack-dev] [nova] [placement] Upgrade concerns with nested Resource Providers

On Thu, May 31, 2018 at 8:26 PM, Eric Fried wrote: > > 1. Make everything perform the pivot on compute node start (which can be > >re-used by a CLI tool for the offline case) > > 2. Make everything default to non-nested inventory at first, and provide > >a way to migrate a compute node an

Re: [openstack-dev] [nova][osc] Documenting compute API microversion gaps in OSC

On Fri, Jun 8, 2018 at 3:35 AM, Matt Riedemann wrote: > I've started an etherpad [1] to identify the compute API microversion gaps > in python-openstackclient. > > It's a small start right now so I would appreciate some help on this, even > just a few people looking at a couple of these per day w

Re: [openstack-dev] [nova] Nominating Stephen Finucane for nova-core

Le 02/12/2016 16:22, Matt Riedemann a écrit : > I'm proposing that we add Stephen Finucane to the nova-core team. > Stephen has been involved with nova for at least around a year now, > maybe longer, my ability to tell time in nova has gotten fuzzy over the > years. Regardless, he's always been e

Re: [openstack-dev] [Blazar] Blazar weekly teem meeting starts again

Le 05/12/2016 05:45, Masahito MUROI a écrit : > Hi Stackers, > > I'm happy to announce it in openstack-dev ML that weekly Blazar team > meeting is going to start again from 6th Dec. > > Some of folks who are interested in resource reservation feature met > together in Barcelona summit and agree

Re: [openstack-dev] [nova] placement/resource providers update 4

Le 06/12/2016 22:02, Ed Leafe a écrit : > On Dec 6, 2016, at 2:42 PM, Jay Pipes wrote: > >> Oh, absolutely, I wasn't arguing about length of URI or anything. >> >> To be clear, I could either go the above route or even do a POST >> /resource_providers that returns a list of resource providers

Re: [openstack-dev] [nova] Is this a correct use of scheduler hints and nova-scheduler

Le 07/12/2016 04:21, Zhenyu Zheng a écrit : > Hi all, > > I want to ask a question about using scheduler-hints, could we add > custom scheduler keys to work with our custom filters? Is it designed to > allow vendors add own custom filters and keys? > I tend to disagree with that approach from

Re: [openstack-dev] [nova] placement/resource providers update 4

Le 07/12/2016 01:07, melanie witt a écrit : > On Tue, 6 Dec 2016 16:04:14 -0500, Jay Pipes wrote: >> We're discussing only doing: >> >> GET /resource_providers? >> >> Once we start doing claims in the scheduler, we'll have the ability to >> do: >> >> POST /allocations >> { >> > all kinds o

Re: [openstack-dev] [nova] placement/resource providers update 4

Le 08/12/2016 02:28, Jay Pipes a écrit : > On 12/07/2016 07:06 PM, Matt Riedemann wrote: >> On 12/7/2016 2:40 AM, Sylvain Bauza wrote: >>> >>> FWIW, I think POST is not that complex and allows us to have room for >>> further request information like traits,

Re: [openstack-dev] [nova] placement/resource providers update 5

Le 09/12/2016 15:50, Chris Dent a écrit : > > A shorter resource provider placement update this week. In part this > is because some of the things to think about from last week[0] got > resolved. What's below is essentially a collection of pending work > related to resource providers and the pla

Re: [openstack-dev] [nova] Upgrade readiness check notes

Le 16/12/2016 03:53, Matt Riedemann a écrit : > A few of us have talked about writing a command to tell when you're > ready to upgrade (restart services with new code) for Ocata because we > have a few things landing in Ocata which are going from optional to > required, namely cells v2 and the pl

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 07:31, Ghanshyam Mann a écrit : > Changing placement API port to 8780 [1], hope this is not being used by any > services. > > But I am not sure how to check all used port currently as wiki does not seems > to have all. > > .. [1] https://review.openstack.org/#/c/412770/ > FW

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 09:12, Sylvain Bauza a écrit : > > > Le 20/12/2016 07:31, Ghanshyam Mann a écrit : >> Changing placement API port to 8780 [1], hope this is not being used by any >> services. >> >> But I am not sure how to check all used port currently as wi

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 09:29, Sylvain Bauza a écrit : > > > Le 20/12/2016 09:12, Sylvain Bauza a écrit : >> >> >> Le 20/12/2016 07:31, Ghanshyam Mann a écrit : >>> Changing placement API port to 8780 [1], hope this is not being used by any >>> services. &g

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 10:20, Chris Dent a écrit : > On Tue, 20 Dec 2016, Sylvain Bauza wrote: > >> Before moving forward and picking yet another port that could trample >> another service, I'd rather prefer first that Senlin jobs would >> temporarely disable the placemen

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 10:26, Sylvain Bauza a écrit : > > > Le 20/12/2016 10:20, Chris Dent a écrit : >> On Tue, 20 Dec 2016, Sylvain Bauza wrote: >> >>> Before moving forward and picking yet another port that could trample >>> another service, I'

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

Le 20/12/2016 14:30, Jay Pipes a écrit : > On 12/20/2016 08:03 AM, Sean Dague wrote: >> On 12/20/2016 07:53 AM, Sylvain Bauza wrote: >>> Le 20/12/2016 10:26, Sylvain Bauza a écrit : >>>> Le 20/12/2016 10:20, Chris Dent a écrit : >>>>> On Tue, 20 Dec 2

[openstack-dev] [nova] [placement] Ocata upgrade procedure and problems when it's optional in Newton

Aloha folks, Recently, I was discussing with TripleO folks. Disclaimer, I don't think it's only a TripleO related discussion but rather a larger one for all our deployers. So, the question I was asked was about how to upgrade from Newton to Ocata for the Placement API when the deployer is not usi

Re: [openstack-dev] [nova] [placement] Ocata upgrade procedure and problems when it's optional in Newton

Le 10/01/2017 14:49, Sylvain Bauza a écrit : > Aloha folks, > > Recently, I was discussing with TripleO folks. Disclaimer, I don't think > it's only a TripleO related discussion but rather a larger one for all > our deployers. > > So, the question I was aske

Re: [openstack-dev] [infra] placement job is busted in stable/newton (NO MORE HOSTS LEFT)

Le 11/01/2017 02:03, Matt Riedemann a écrit : > I'm trying to sort out failures in the placement job in stable/newton > job where the tests aren't failing but it's something in the host > cleanup step that blows up. > > Looking here I see this: > > http://logs.openstack.org/57/416757/1/check/ga

Re: [openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

Le 19/01/2017 16:27, Matt Riedemann a écrit : > Sylvain and I were talking about how he's going to work placement > microversion requests into his filter scheduler patch [1]. He needs to > make requests to the placement API with microversion 1.4 [2] or later > for resource provider filtering on s

Re: [openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

Le 19/01/2017 17:00, Matt Riedemann a écrit : > On 1/19/2017 9:43 AM, Sylvain Bauza wrote: >> >> >> Le 19/01/2017 16:27, Matt Riedemann a écrit : >>> Sylvain and I were talking about how he's going to work placement >>> microversion requests into

Re: [openstack-dev] [nova] Do not recheck changes until 422709 is merged

Le 20/01/2017 04:16, Matt Riedemann a écrit : > On 1/19/2017 5:09 PM, Matt Riedemann wrote: >> On 1/19/2017 10:56 AM, Matt Riedemann wrote: >>> The py35 unit test job is broken for Nova until this patch is merged: >>> >>> https://review.openstack.org/#/c/422709/ >>> >>> So please hold off on the

Re: [openstack-dev] [nova] Order of n-api (placement) and n-sch upgrades for Ocata

Le 19/01/2017 21:39, Matt Riedemann a écrit : > On Thu, Jan 19, 2017 at 2:29 PM, Alex Schultz > wrote: >> >> What are these issues? My original message was to highlight one >> particular deployment type which is completely independent of >> how things get packaged in the traditional sense of t

[openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Hey folks, tl;dr: should we GET /resource_providers for only the related resources that correspond to enabled filters ? Explanation below why even if I know we have a current consensus, maybe we should discuss again about it. I'm still trying to implement https://review.openstack.org/#/c/417961/

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 22/01/2017 22:40, Sylvain Bauza a écrit : > Hey folks, > > tl;dr: should we GET /resource_providers for only the related resources > that correspond to enabled filters ? Explanation below why even if I > know we have a current consensus, maybe we should discuss again about

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 23/01/2017 15:11, Jay Pipes a écrit : > On 01/22/2017 04:40 PM, Sylvain Bauza wrote: >> Hey folks, >> >> tl;dr: should we GET /resource_providers for only the related resources >> that correspond to enabled filters ? > > No. Have administrators set the al

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 23/01/2017 15:18, Sylvain Bauza a écrit : > > > Le 23/01/2017 15:11, Jay Pipes a écrit : >> On 01/22/2017 04:40 PM, Sylvain Bauza wrote: >>> Hey folks, >>> >>> tl;dr: should we GET /resource_providers for only the related resources >>>

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 24/01/2017 22:22, Dan Smith a écrit : >> No. Have administrators set the allocation ratios for the resources they >> do not care about exceeding capacity to a very high number. >> >> If someone previously removed a filter, that doesn't mean that the >> resources were not consumed on a host. It

Re: [openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

Le 25/01/2017 05:10, Matt Riedemann a écrit : > On 1/24/2017 2:57 PM, Matt Riedemann wrote: >> On 1/24/2017 2:38 PM, Sylvain Bauza wrote: >>> >>> It's litterally 2 days before FeatureFreeze and we ask operators to >>> change their cloud right now ?

Re: [openstack-dev] [nova] Latest and greatest on trying to get n-sch to require placement

Le 26/01/2017 05:42, Matt Riedemann a écrit : > This is my public hand off to Sylvain for the work done tonight. > Thanks Matt for your help yesterday, was awesome to count you in even you're personally away. > Starting with the multinode grenade failure in the nova patch to > integrate place

Re: [openstack-dev] [nova] Latest and greatest on trying to get n-sch to require placement

Le 26/01/2017 15:14, Ed Leafe a écrit : > On Jan 26, 2017, at 7:50 AM, Sylvain Bauza wrote: >> >> That's where I think we have another problem, which is bigger than the >> corner case you mentioned above : when upgrading from Newton to Ocata, >> we said that all

Re: [openstack-dev] [nova] Latest and greatest on trying to get n-sch to require placement

Le 26/01/2017 05:42, Matt Riedemann a écrit : > This is my public hand off to Sylvain for the work done tonight. > > Starting with the multinode grenade failure in the nova patch to > integrate placement with the filter scheduler: > > https://review.openstack.org/#/c/417961/ > > The test_sched

Re: [openstack-dev] [keystone] Do we really need two listening ports ?

Le 01/02/2017 13:58, Thomas Goirand a écrit : > On 02/01/2017 10:54 AM, Attila Fazekas wrote: >> Hi all, >> >> Typically we have two keystone service listening on two separate ports >> 35357 and 5000. >> >> Historically one of the port had limited functionality, but today I do >> not see why we w

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

Le 16/02/2017 10:17, Neil Jerram a écrit : > On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow > wrote: > > Radical idea, have each project (not libraries) contain a dockerfile > that builds the project into a deployable unit (or multiple dockerfiles > for

Re: [openstack-dev] [chef] Making the Kitchen Great Again: A Retrospective on OpenStack & Chef

Le 16/02/2017 18:42, Alex Schultz a écrit : > On Thu, Feb 16, 2017 at 9:12 AM, Ed Leafe wrote: >> On Feb 16, 2017, at 10:07 AM, Doug Hellmann wrote: >> >>> When we signed off on the Big Tent changes we said competition >>> between projects was desirable, and that deployers and contributors >>>

Re: [openstack-dev] [nova] Will unshelving an offloaded instance respect the original AZ?

Le 20/02/2017 09:41, Jay Pipes a écrit : > On 02/18/2017 01:46 PM, Matt Riedemann wrote: >> I haven't fully dug into testing this, but I got wondering about this >> question from reviewing a change [1] which would make the unshelve >> operation start to check the volume AZ compared to the instanc

Re: [openstack-dev] [nova] Call for upstream training liaison

I can help here even I'm not sure I'll be going to the Summit yet. Le 21 févr. 2017 14:48, "Matt Riedemann" a écrit : > If you haven't seen this yet [1] there is going to be an upstream training > meeting at the PTG on Wednesday 2/22 at 12ET to talk about upstream > training and what liaisons fr

Re: [openstack-dev] [nova]Placement api on https

Le 22/02/2017 05:14, Gyorgy Szombathelyi a écrit : > Hi! > > As the placement API is mandatory in Ocata, I found out that you cannot give > a custom CA cert or skip the validation in its clients. That would be bad, as > you can give a custom CA cert in the [keystone_authtoken] section, but not

Re: [openstack-dev] [nova] NUMA-aware live migration: easy but incomplete vs complete but hard

On Tue, Jun 19, 2018 at 9:59 PM, Artom Lifshitz wrote: > > Adding > > claims support later on wouldn't change any on-the-wire messaging, it > would > > just make things work more robustly. > > I'm not even sure about that. Assuming [1] has at least the right > idea, it looks like it's an either-o

Re: [openstack-dev] [stable][nova] Nominating melwitt for nova stable core

On Wed, Aug 29, 2018 at 4:42 AM, Tony Breeds wrote: > On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote: > > I hereby nominate Melanie Witt for nova stable core. Mel has shown that > she > > knows the stable branch policy and is also an active reviewer of nova > stable > > changes. >

Re: [openstack-dev] [nova][placement] Freezing placement for extraction

On Thu, Aug 30, 2018 at 6:34 PM, Eric Fried wrote: > Greetings. > > The captains of placement extraction have declared readiness to begin > the process of seeding the new repository (once [1] has finished > merging). As such, we are freezing development in the affected portions > of the openstack

Re: [openstack-dev] [nova] [placement] extraction (technical) update

On Wed, Sep 5, 2018 at 3:56 PM, Matt Riedemann wrote: > On 9/5/2018 8:39 AM, Dan Smith wrote: > >> Why not? >> > > Because of the versions table as noted earlier. Up until this point no one > had mentioned that but it would be an issue. > > >> I think the safest/cleanest thing to do here is renum

Re: [openstack-dev] About microversion setting to enable nested resource provider

code to set it? > > > > BR. > > Naichuan Sun > > > > -Original Message- > > From: Jay Pipes [mailto:jaypi...@gmail.com] > > Sent: Thursday, September 13, 2018 9:19 PM > > To: Naichuan Sun ; OpenStack Development > Mailing List (not for usage

Re: [openstack-dev] About microversion setting to enable nested resource provider

your afternoons) -Sylvain > > > Thank you very much. > > > > BR. > > Naichuan Sun > > > > *From:* Sylvain Bauza [mailto:sba...@redhat.com] > *Sent:* Thursday, September 13, 2018 11:47 PM > *To:* OpenStack Development Mailing List (not for usage questions) < &

Re: [openstack-dev] About microversion setting to enable nested resource provider

w_child() method is used to create new child > providers: > > https://github.com/openstack/nova/blob/82270cc261f6c1d9d2cc3 > 86f1fb445dd66023f75/nova/compute/provider_tree.py#L411 > > Hope that makes sense, > -jay > > Thank very much. >> >> BR. >> >>

Re: [openstack-dev] [election][tc]Question for candidates about global reachout

Le lun. 17 sept. 2018 à 15:32, Jeremy Stanley a écrit : > On 2018-09-16 14:14:41 +0200 (+0200), Jean-philippe Evrard wrote: > [...] > > - What is the problem joining Wechat will solve (keeping in mind the > > language barrier)? > > As I understand it, the suggestion is that mere presence of proje

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley a écrit : > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: > [...] > > I can understand that IRC cannot be used in China which is very > > painful and mostly it is used weChat. > [...] > > I have yet to hear anyone provide first-hand conf

Re: [openstack-dev] [Openstack-sigs] [Openstack-operators] [tc]Global Reachout Proposal

Le mar. 18 sept. 2018 à 16:00, Thierry Carrez a écrit : > Sylvain Bauza wrote: > > > > > > Le mar. 18 sept. 2018 à 14:41, Jeremy Stanley > <mailto:fu...@yuggoth.org>> a écrit : > > > > On 2018-09-18 11:26:57 +0900 (+0900), Ghanshyam Mann wrote: &

Re: [openstack-dev] Forum Topic Submission Period

Le mer. 19 sept. 2018 à 00:41, Jimmy McArthur a écrit : > Hey Matt, > > > Matt Riedemann wrote: > > > > Just a process question. > > Good question. > > I submitted a presentation for the normal marketing blitz part of the > > summit which wasn't accepted (I'm still dealing with this emotionally,

Re: [openstack-dev] [nova] Stein PTG summary

Thanks for the recap email, Mel. Just a question inline for all the people that were in the room by Wednesday. Le jeu. 27 sept. 2018 à 00:10, melanie witt a écrit : > Hello everybody, > > I've written up a high level summary of the discussions we had at the > PTG -- please feel free to reply to

Re: [openstack-dev] [nova] Stein PTG summary

On Thu, Sep 27, 2018 at 2:46 AM Matt Riedemann wrote: > On 9/26/2018 5:30 PM, Sylvain Bauza wrote: > > So, during this day, we also discussed about NUMA affinity and we said > > that we could possibly use nested resource providers for NUMA cells in > > Stein, but give

Re: [openstack-dev] [Openstack-operators] [ironic] [nova] [tripleo] Deprecation of Nova's integration with Ironic Capabilities and ComputeCapabilitiesFilter

On Fri, Sep 28, 2018 at 12:50 AM melanie witt wrote: > On Thu, 27 Sep 2018 17:23:26 -0500, Matt Riedemann wrote: > > On 9/27/2018 3:02 PM, Jay Pipes wrote: > >> A great example of this would be the proposed "deploy template" from > >> [2]. This is nothing more than abusing the placement traits AP

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit : > IIUC, the primary thing the force flag was intended to do - allow an > instance to land on the requested destination even if that means > oversubscription of the host's resources - doesn't happen anymore since > we started making the destination

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Le mar. 9 oct. 2018 à 17:09, Balázs Gibizer a écrit : > > > On Tue, Oct 9, 2018 at 4:56 PM, Sylvain Bauza > wrote: > > > > > > Le mar. 9 oct. 2018 à 16:39, Eric Fried a > > écrit : > >> IIUC, the primary thing the force flag was intended to do - al

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Shit, I forgot to add openstack-operators@... Operators, see my question for you here : > Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit : > >> IIUC, the primary thing the force flag was intended to do - allow an >> instance to land on the requested destination even if that means >> oversubscri

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

> Shit, I forgot to add openstack-operators@... > Operators, see my question for you here : > > >> Le mar. 9 oct. 2018 à 16:39, Eric Fried a écrit : >> >>> IIUC, the primary thing the force flag was intended to do - allow an >>> instance to land on the requested destination even if that means >>>

Re: [openstack-dev] [nova] Supporting force live-migrate and force evacuate with nested allocations

Le mer. 10 oct. 2018 à 12:32, Balázs Gibizer a écrit : > Hi, > > Thanks for all the feedback. I feel the following consensus is forming: > > 1) remove the force flag in a new microversion. I've proposed a spec > about that API change [1] > > Thanks, will look at it. > 2) in the old microversion

Re: [openstack-dev] [nova] shall we do a spec review day next tuesday oct 23?

Le lun. 15 oct. 2018 à 19:07, melanie witt a écrit : > Hey all, > > Milestone s-1 is coming up next week on Thursday Oct 25 [1] and I was > thinking it would be a good idea to have a spec review day next week on > Tuesday Oct 23 to spend some focus on spec reviews together. > > Spec freeze is s-2

Re: [openstack-dev] [NOVA] nova GPU suppot and find GPU type

On Tue, Oct 30, 2018 at 12:21 AM Manuel Sopena Ballesteros < manuel...@garvan.org.au> wrote: > Dear Nova community, > > > > This is the first time I work with GPUs. > > > > I have a Dell C4140 with x4 Nvidia Tesla V100 SXM2 16GB I would like to > setup on Openstack Rocky. > > > > I checked the doc

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

Le 15/09/2016 03:21, Matt Riedemann a écrit : I'm looking for other input on a question I have in this change: https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py We've had a few patches like this where we don't (soft) delete entries related to an instance when that instance

Re: [openstack-dev] [nova] Question about fixing missing soft deleted rows

Le 15/09/2016 14:21, Sean Dague a écrit : On 09/14/2016 09:21 PM, Matt Riedemann wrote: I'm looking for other input on a question I have in this change: https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py We've had a few patches like this where we don't (soft) delete entries

Re: [openstack-dev] [nova] TL; DR A proposed subsystem maintainer model

Le 20/09/2016 13:07, Matthew Booth a écrit : * +A is reserved for cores. * A subsystem maintainer's domain need not be defined by the directory tree: subteams are a good initial model. * A maintainer should only +2 code in their own domain in good faith, enforced socially, not technically.

<    1   2   3   4   5   6   7   >