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

On 2/5/2018 9:00 PM, Matt Riedemann wrote: 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

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

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

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

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 >

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 5:24 AM, melanie witt wrote: > Hello Stackers, > > This is a heads up to any of you using the AggregateCoreFilter, >

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

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 overcommit ratios per aggregate rather than per compute node in <= Newton.