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

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

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

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

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

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

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

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 gi

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] 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] [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 wro

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

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

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

d 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. >> >> Naichuan Sun

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

s) -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) < > openstack-d

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

? > > > > 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 questions)

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

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

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] 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

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

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

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:

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 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 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 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 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] [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 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] [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 f

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

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 do this ? By the resource

[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

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

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

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

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

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.

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

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

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

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] 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] [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

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

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

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

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

Re: [openstack-dev] [nova] Is there any reason to exclude originally failed build hosts during live migration?

On Wed, Sep 20, 2017 at 10:15 PM, melanie witt wrote: > On Wed, 20 Sep 2017 13:47:18 -0500, Matt Riedemann wrote: > >> Presumably there was a good reason why the instance failed to build on a >> host originally, but that could be for any number of reasons: resource >> claim

Re: [openstack-dev] [nova] Should we add the 'force' option to the cold migrate API too?

On Wed, Aug 30, 2017 at 5:09 PM, Matt Riedemann wrote: > Given the recent bugs [1][2] due to the force flag in the live migrate and > evacuate APIs related to Placement, and some other long standing bugs about > bypassing the scheduler [3], I don't think we should add the

Re: [openstack-dev] [nova] RequestSpec questions about force_hosts/nodes and requested_destination

2017-08-30 15:43 GMT+02:00 Sylvain Bauza <sylvain.ba...@gmail.com>: > Still on PTO for one day, but I'll try to answer. Sorry for the delay, was > out traveling. > > > 2017-08-21 23:09 GMT+02:00 Matt Riedemann <mriede...@gmail.com>: > >> I don't dabble in the

Re: [openstack-dev] [nova] RequestSpec questions about force_hosts/nodes and requested_destination

Still on PTO for one day, but I'll try to answer. Sorry for the delay, was out traveling. 2017-08-21 23:09 GMT+02:00 Matt Riedemann : > I don't dabble in the RequestSpec code much, but in trying to fix bug > 1712008 [1] I'm venturing in there and have some questions. This

Re: [openstack-dev] [nova] Proposing Balazs Gibizer for nova-core

2017-08-29 18:02 GMT+02:00 Matt Riedemann : > On 8/22/2017 8:18 PM, Matt Riedemann wrote: > >> I'm proposing that we add gibi to the nova core team. He's been around >> for awhile now and has shown persistence and leadership in the >> multi-release versioned notifications

Re: [openstack-dev] [nova] bug triage experimentation

Le 23/06/2017 18:52, Sean Dague a écrit : > The Nova bug backlog is just over 800 open bugs, which while > historically not terrible, remains too large to be collectively usable > to figure out where things stand. We've had a few recent issues where we > just happened to discover upgrade bugs

Re: [openstack-dev] [ironic][nova] Goodbye^W See you later

Le 08/06/2017 14:45, Jim Rollenhagen a écrit : > Hey friends, > > I've been mostly missing for the past six weeks while looking for a new > job, so maybe you've forgotten me already, maybe not. I'm happy to tell > you I've found one that I think is a great opportunity for me. But, I'm > sad to

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

Le 06/06/2017 15:03, Edward Leafe a écrit : > On Jun 6, 2017, at 4:14 AM, Sylvain Bauza <sba...@redhat.com > <mailto:sba...@redhat.com>> wrote: >> >> The Plan A option you mention hides the complexity of the >> shared/non-shared logic but to the price that i

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 05/06/2017 23:22, Ed Leafe a écrit : > We had a very lively discussion this morning during the Scheduler > subteam meeting, which was continued in a Google hangout. The > subject was how to handle claiming resources when the Resource > Provider

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 15:14, Chris Dent a écrit : > On Thu, 18 May 2017, Matt Riedemann wrote: > >> We didn't really get into this during the forum session, but there are >> different opinions within the nova dev team on how to do claims in the >> controller services (conducto

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 12:19, John Garbutt a écrit : > On 19 May 2017 at 10:03, Sylvain Bauza <sba...@redhat.com> wrote: >> >> >> Le 19/05/2017 10:02, Sylvain Bauza a écrit : >>> >>> >>> Le 19/05/2017 02:55, Matt Riedemann a écrit : &g

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

Le 19/05/2017 10:02, Sylvain Bauza a écrit : > > > Le 19/05/2017 02:55, Matt Riedemann a écrit : >> The etherpad for this session is here [1]. The goal for this session was >> to inform operators and get feedback on the plan for what we're doing >> with movi

Re: [openstack-dev] [nova] Boston Forum session recap - claims in the scheduler (or conductor)

urprise to an operator. > > We didn't really get into this during the forum session, but there are > different opinions within the nova dev team on how to do claims in the > controller services (conductor vs scheduler). Sylvain Bauza has a series > which uses the conductor servi

Re: [openstack-dev] [nova][blazar][scientific] advanced instance scheduling: reservations and preeemption - Forum session

You can also count on me for discussing about what was Blazar previously and how Nova could help it ;-) -Sylvain Le 1 mai 2017 21:53, "Jay Pipes" a écrit : > On 05/01/2017 03:39 PM, Blair Bethwaite wrote: > >> Hi all, >> >> Following up to the recent thread

Re: [openstack-dev] [Blazar] Meeting time slots in Boston

Le 21/04/2017 06:41, Masahito MUROI a écrit : > Hi all, > > Thanks for choosing time slots! Based on the table of Doodle, I'd like > to pick following two slots for Blazar team meeting. > > 1. 1pm-4pm on Monday for Blazar's internal features > 2. 9am-10am or 11am on Thursday for discussions

Re: [openstack-dev] [nova] What is the difference between default_schedule_zone and default_availability_zone?

Le 12/04/2017 18:24, Matt Riedemann a écrit : > I'm hoping someone more learned can teach me. These two options sound > very similar, and are thus very confusing. They are also both in the > [DEFAULT] config option group, but defined in different places [1][2]. > > The help text for one says: >

Re: [openstack-dev] [nova] How can i check if an instance belongs to host-aggregate

Le 29/03/2017 10:23, Pradeep Singh a écrit : > Hello, > > I want to filter out some instances(to avoid some operation on them) > which are scheduled on host-aggregates. > > How can i filter out these instances from all instances list in my cloud. > Aggregates are host-based. So, if you want

Re: [openstack-dev] [nova] [placement] small wart in the resource class API

Le 16/03/2017 14:12, Chris Dent a écrit : > > (This message is a question asking "should we fix this?" and "if so, > I guess that needs spec, since it is a microversion change, but > would an update to the existing spec be good enough?") > > We have a small wart in the API for creating and

Re: [openstack-dev] [nova] [placement] experimenting with extracting placement

Le 13/03/2017 15:17, Jay Pipes a écrit : > On 03/13/2017 09:16 AM, Sylvain Bauza wrote: >> Please don't. >> Having a separate repository would mean that deployers would need to >> implement a separate package for placement plus discussing about >> how/when

Re: [openstack-dev] [nova] [placement] experimenting with extracting placement

Le 13/03/2017 14:59, Jay Pipes a écrit : > On 03/13/2017 08:41 AM, Chris Dent wrote: >> >> From the start we've been saying that it is probably right for the >> placement service to have its own repository. This is aligned with >> the long term goal of placement being useful to many services,

Re: [openstack-dev] [nova] [placement] experimenting with extracting placement

Le 13/03/2017 14:21, Sean Dague a écrit : > On 03/13/2017 09:16 AM, Sylvain Bauza wrote: >> >> >> Le 13/03/2017 13:41, Chris Dent a écrit : >>> >>> From the start we've been saying that it is probably right for the >>> placement ser

Re: [openstack-dev] [nova] [placement] experimenting with extracting placement

Le 13/03/2017 13:41, Chris Dent a écrit : > > From the start we've been saying that it is probably right for the > placement service to have its own repository. This is aligned with > the long term goal of placement being useful to many services, not > just nova, and also helps to keep

Re: [openstack-dev] [nova][docs] Broken nova instructions

Le 09/03/2017 11:25, Alexandra Settle a écrit : > Hi everyone, > > > > The installation guide for docs.o.o is currently broken and requires > immediate attention from the doc and nova teams. > > > > I have moved the relevant bug[0] to be CRITICAL at request. Brian Moss > (bmoss) and Amy

Re: [openstack-dev] [nova] Freeze dates for Pike

Le 02/03/2017 23:46, Matt Riedemann a écrit : > I mentioned this in the nova meeting today [1] but wanted to post to the > ML for feedback. > > We didn't talk about spec or feature freeze dates at the PTG. The Pike > release schedule is [2]. > > Spec freeze > --- > > In Newton and

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

Le 27/02/2017 15:50, Matt Riedemann a écrit : > On 2/26/2017 11:25 PM, Clint Byrum wrote: >> >> You have taken the folder approach, and that is a bit less complicated >> to set up than sup+offlineimap, but still does require that you know >> how to filter by tag. It also means that you are

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

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 >

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

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,

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

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

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

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 <sba...@redhat.com> 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,

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

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 ? L

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.

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

[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

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

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 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 h

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

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: > >

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 asked was abou

[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

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

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'd rat

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 placement-* s

  1   2   3   4   5   6   >