Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

Hi Dave,

On Tue, May 1, 2018 at 4:30 AM, Dave Holland  wrote:
> On Mon, Apr 30, 2018 at 12:41:21PM -0400, Mathieu Gagné wrote:
>> Weighers for baremetal cells:
>> * ReservedHostForTenantWeigher [7]
> ...
>> [7] Used to favor reserved host over non-reserved ones based on project.
>
> Hello Mathieu,
>
> we are considering writing something like this, for virtual machines not
> for baremetal. Our use case is that a project buying some compute
> hardware is happy for others to use it, but when the compute "owner"
> wants sole use of it, other projects' instances must be migrated off or
> killed; a scheduler weigher like this might help us to minimise the
> number of instances needing migration or termination at that point.
> Would you be willing to share your source code please?
>

I'm not sure how battle-tested this code is to be honest but here it is:
https://gist.github.com/mgagne/659ca02e63779802de6f7aec8cda612a

I had to merge 2 files in one (the weigher and the conf) so I'm not
sure if it still works but I think you will get the idea.

To use it, you need to define the "reserved_for_tenant_id" Ironic node
property with the project ID to reserve it. (through Ironic API)

This code also assumes you already filtered out hosts which are
reserved for a different tenant. I included that code in the gist too.

On a side note, our technicians generally use the forced host feature
of Nova to target specific Ironic nodes:
https://docs.openstack.org/nova/pike/admin/availability-zones.html

But if the customer buys and reserves some machines, he should get
them first before the ones in the "public pool".

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Tim Bell]

You may also need something like pre-emptible instances to arrange the clean up 
of opportunistic VMs when the owner needs his resources back. Some details on 
the early implementation at 
http://openstack-in-production.blogspot.fr/2018/02/maximizing-resource-utilization-with.html.

If you're in Vancouver, we'll be having a Forum session on this 
(https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21787/pre-emptible-instances-the-way-forward)
 and notes welcome on the etherpad 
(https://etherpad.openstack.org/p/YVR18-pre-emptible-instances)

It would be good to find common implementations since this is a common scenario 
in the academic and research communities.

Tim

-Original Message-
From: Dave Holland 
Date: Tuesday, 1 May 2018 at 10:40
To: Mathieu Gagné 
Cc: "OpenStack Development Mailing List (not for usage questions)" 
, openstack-operators 

Subject: Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler 
filters survey

On Mon, Apr 30, 2018 at 12:41:21PM -0400, Mathieu Gagné wrote:
> Weighers for baremetal cells:
> * ReservedHostForTenantWeigher [7]
...
> [7] Used to favor reserved host over non-reserved ones based on project.

Hello Mathieu,

we are considering writing something like this, for virtual machines not
for baremetal. Our use case is that a project buying some compute
hardware is happy for others to use it, but when the compute "owner"
wants sole use of it, other projects' instances must be migrated off or
killed; a scheduler weigher like this might help us to minimise the
number of instances needing migration or termination at that point.
Would you be willing to share your source code please?

thanks,
Dave
-- 
** Dave Holland ** Systems Support -- Informatics Systems Group **
** 01223 496923 **Wellcome Sanger Institute, Hinxton, UK**


-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Simon Leinen]

[Resending for a colleague who's not on openstack-dev-- SL.]

Yeap, because of the bug [#1677217] in the standard
AggregateImagePropertiesIsolation filter, we have written a custom
Nova scheduler filter.

The filter AggregateImageOsDistroIsolation is a simplified version the
AggregateImagePropertiesIsolation, based only on the 'os_distro' image
property.
https://github.com/valerytschopp/nova/blob/aggregate_image_isolation/nova/scheduler/filters/aggregate_image_os_distro_isolation.py

[#1677217] https://bugs.launchpad.net/nova/+bug/1677217

Cheers,
Valery

On 29/04/18, 23:29 , "Ed Leafe"  wrote:

> On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:
>> 
>> Based on that, we can definitely say that SameHostFilter and
>> DifferentHostFilter do *not* belong in the defaults. In fact, we got
>> our defaults pretty spot on, based on this admittedly very limited
>> dataset. The only frequently occurring filter that's not in our
>> defaults is AggregateInstanceExtraSpecsFilter.

> Another data point that might be illuminating is: how many sites
> use a custom (i.e., not in-tree) filter or weigher? One of the
> original design tenets of the scheduler was that we did not want to
> artificially limit what people could use to control their deployments,
> but inside of Nova there is a lot of confusion as to whether anyone is
> using anything but the included filters.

> So - does anyone out there rely on a filter and/or weigher that they 
> wrote themselves, and maintain outside of OpenStack?

> -- Ed Leafe





> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Matt Riedemann]

On 4/30/2018 11:41 AM, Mathieu Gagné wrote:

[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
 This is mainly used when enrolling existing nodes already living
on a different system.
 We reserve the node to a special internal user so the customer
cannot reserve
 the node by mistake until the process is completed.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.


See https://review.openstack.org/#/c/565340/ for context on the 
regression mentioned about RequestSpec.user_id.


Thanks Mathieu for jumping in #openstack-nova and discussing it.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

On Mon, Apr 30, 2018 at 1:06 PM, Jay Pipes  wrote:
> Mathieu,
>
> How do you handle issues where compute nodes are associated with multiple
> aggregates and both aggregates have different values for a particular filter
> key?
>
> Is that a human-based validation process to ensure you don't have that
> situation?
>

It's human-based and we are fine with it.

We also have automatic reports which generate stats on those aggregates.
You will visually see it if some hosts are part of multiple aggregates.

If we need an intersection of 2 aggregates, we create a new one and
use it instead.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Jay Pipes]

Mathieu,

How do you handle issues where compute nodes are associated with 
multiple aggregates and both aggregates have different values for a 
particular filter key?


Is that a human-based validation process to ensure you don't have that 
situation?


Best,
-jay

On 04/30/2018 12:41 PM, Mathieu Gagné wrote:

Hi,

On Sun, Apr 29, 2018 at 5:29 PM, Ed Leafe  wrote:

On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:


Based on that, we can definitely say that SameHostFilter and
DifferentHostFilter do *not* belong in the defaults. In fact, we got
our defaults pretty spot on, based on this admittedly very limited
dataset. The only frequently occurring filter that's not in our
defaults is AggregateInstanceExtraSpecsFilter.


Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?


Yes and we have a bunch.

Here are our filters and weighers with explanations.

Filters for cells:
* InstanceTypeClassFilter [0]

Filters for cloud/virtual cells:
* RetryFilter
* AvailabilityZoneFilter
* RamFilter
* ComputeFilter
* AggregateCoreFilter
* ImagePropertiesFilter
* AggregateImageOsTypeIsolationFilter [1]
* AggregateInstanceExtraSpecsFilter
* AggregateProjectsIsolationFilter [2]

Weighers for cloud/virtual cells:
* MetricsWeigher
* AggregateRAMWeigher [3]

Filters for baremetal cells:
* ComputeFilter
* NetworkModelFilter [4]
* TenantFilter [5]
* UserFilter [6]
* RetryFilter
* AvailabilityZoneFilter
* ComputeCapabilitiesFilter
* ImagePropertiesFilter
* ExactRamFilter
* ExactDiskFilter
* ExactCoreFilter

Weighers for baremetal cells:
* ReservedHostForTenantWeigher [7]
* ReservedHostForUserWeigher [8]

[0] Used to scheduler instances based on flavor class found in
extra_specs (virtual/baremetal)
[1] Allows to properly isolated hosts for licensing purposes.
 The upstream filter is not strict as per bugs/reviews/specs:
 * https://bugs.launchpad.net/nova/+bug/1293444
 * https://bugs.launchpad.net/nova/+bug/1677217
 * https://review.openstack.org/#/c/56420/
 * https://review.openstack.org/#/c/85399/
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/462e7fa8417843055aa6da7c5fd51c00
[2] Similar filter to AggregateImageOsTypeIsolationFilter but for projects.
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/d729ccb512b0434568ffb094441f643f
[3] Allows to change stacking behavior based on the 'ram_weight_multiplier'
 aggregate key. (emptiest/fullest)
 Our custom implementation for Mitaka:
 https://gist.github.com/mgagne/65f033cbc5fdd4c8d1f45e90c943a5f4
[4] Used to filter Ironic nodes based on supported network models as requested
 by flavor extra_specs. We support JIT network configuration (flat/bond) and
 need to know which nodes support what network models beforehand.
[5] Used to filter Ironic nodes based on the 'reserved_for_tenant_id'
Ironic node property.
 This is used to reserve Ironic node to specific projects.
 Some customers order lot of machines in advance. We reserve those for them.
[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
 This is mainly used when enrolling existing nodes already living
on a different system.
 We reserve the node to a special internal user so the customer
cannot reserve
 the node by mistake until the process is completed.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.
[7] Used to favor reserved host over non-reserved ones based on project.
[8] Used to favor reserved host over non-reserved ones based on user.
 Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mathieu Gagné]

Hi,

On Sun, Apr 29, 2018 at 5:29 PM, Ed Leafe  wrote:
> On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:
>>
>> Based on that, we can definitely say that SameHostFilter and
>> DifferentHostFilter do *not* belong in the defaults. In fact, we got
>> our defaults pretty spot on, based on this admittedly very limited
>> dataset. The only frequently occurring filter that's not in our
>> defaults is AggregateInstanceExtraSpecsFilter.
>
> Another data point that might be illuminating is: how many sites use a custom 
> (i.e., not in-tree) filter or weigher? One of the original design tenets of 
> the scheduler was that we did not want to artificially limit what people 
> could use to control their deployments, but inside of Nova there is a lot of 
> confusion as to whether anyone is using anything but the included filters.
>
> So - does anyone out there rely on a filter and/or weigher that they wrote 
> themselves, and maintain outside of OpenStack?

Yes and we have a bunch.

Here are our filters and weighers with explanations.

Filters for cells:
* InstanceTypeClassFilter [0]

Filters for cloud/virtual cells:
* RetryFilter
* AvailabilityZoneFilter
* RamFilter
* ComputeFilter
* AggregateCoreFilter
* ImagePropertiesFilter
* AggregateImageOsTypeIsolationFilter [1]
* AggregateInstanceExtraSpecsFilter
* AggregateProjectsIsolationFilter [2]

Weighers for cloud/virtual cells:
* MetricsWeigher
* AggregateRAMWeigher [3]

Filters for baremetal cells:
* ComputeFilter
* NetworkModelFilter [4]
* TenantFilter [5]
* UserFilter [6]
* RetryFilter
* AvailabilityZoneFilter
* ComputeCapabilitiesFilter
* ImagePropertiesFilter
* ExactRamFilter
* ExactDiskFilter
* ExactCoreFilter

Weighers for baremetal cells:
* ReservedHostForTenantWeigher [7]
* ReservedHostForUserWeigher [8]

[0] Used to scheduler instances based on flavor class found in
extra_specs (virtual/baremetal)
[1] Allows to properly isolated hosts for licensing purposes.
The upstream filter is not strict as per bugs/reviews/specs:
* https://bugs.launchpad.net/nova/+bug/1293444
* https://bugs.launchpad.net/nova/+bug/1677217
* https://review.openstack.org/#/c/56420/
* https://review.openstack.org/#/c/85399/
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/462e7fa8417843055aa6da7c5fd51c00
[2] Similar filter to AggregateImageOsTypeIsolationFilter but for projects.
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/d729ccb512b0434568ffb094441f643f
[3] Allows to change stacking behavior based on the 'ram_weight_multiplier'
aggregate key. (emptiest/fullest)
Our custom implementation for Mitaka:
https://gist.github.com/mgagne/65f033cbc5fdd4c8d1f45e90c943a5f4
[4] Used to filter Ironic nodes based on supported network models as requested
by flavor extra_specs. We support JIT network configuration (flat/bond) and
need to know which nodes support what network models beforehand.
[5] Used to filter Ironic nodes based on the 'reserved_for_tenant_id'
Ironic node property.
This is used to reserve Ironic node to specific projects.
Some customers order lot of machines in advance. We reserve those for them.
[6] Used to filter Ironic nodes based on the 'reserved_for_user_id'
Ironic node property.
This is mainly used when enrolling existing nodes already living
on a different system.
We reserve the node to a special internal user so the customer
cannot reserve
the node by mistake until the process is completed.
Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.
[7] Used to favor reserved host over non-reserved ones based on project.
[8] Used to favor reserved host over non-reserved ones based on user.
Latest version of Nova dropped user_id from RequestSpec. We had to
add it back.

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mikhail Medvedev]

On Mon, Apr 30, 2018 at 8:46 AM, Jay Pipes  wrote:
> On 04/30/2018 09:18 AM, Mikhail Medvedev wrote:
>>
>> On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:
>>>
>>>
>>> Another data point that might be illuminating is: how many sites use a
>>> custom (i.e., not in-tree) filter or weigher? One of the original design
>>> tenets of the scheduler was that we did not want to artificially limit what
>>> people could use to control their deployments, but inside of Nova there is a
>>> lot of confusion as to whether anyone is using anything but the included
>>> filters.
>>>
>>> So - does anyone out there rely on a filter and/or weigher that they
>>> wrote themselves, and maintain outside of OpenStack?
>>>
>>
>> Internal cloud that is used for Power KVM CI single use VMs:
>>
>> AvailabilityZoneFilter
>> AggregateMultiTenancyIsolation
>> RetryFilter
>> RamFilter
>> ComputeFilter
>> ComputeCapabilitiesFilter
>> ImagePropertiesFilter
>> CoreFilter
>> NumInstancesFilter *
>> NUMATopologyFilter
>>
>> NumInstancesFilter is a custom weigher I have added that returns
>> negative number of instances on a host. Using it this way gives an
>> even spread of instances over the compute nodes up to a point the
>> compute cores are filled up evenly, then it overflows to the compute
>> nodes with more CPU cores. Maybe it is possible to achieve the same
>> with existing filters, at the time I did not see how.

Correction: above describes custom weigher I've added, not the in-tree
NumInstancesFilter.

>
>
> Hi Mikhail,
>
> Did you mean to say you created a new *weigher*, not filter?

Jay, thanks for spotting this, been awhile since I've done it.
NumInstancesFilter is a standard filter, so I obviously did not write
it.

I've added a custom weigher that I have created
(scheduler_weight_classes=pkvmci-os.nova.scheduler.weights.instance.InstanceWeigher)
and maintain locally.

>
> Best,
> -jay
>
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Jay Pipes]

On 04/30/2018 09:18 AM, Mikhail Medvedev wrote:

On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:


Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?



Internal cloud that is used for Power KVM CI single use VMs:

AvailabilityZoneFilter
AggregateMultiTenancyIsolation
RetryFilter
RamFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
CoreFilter
NumInstancesFilter *
NUMATopologyFilter

NumInstancesFilter is a custom weigher I have added that returns
negative number of instances on a host. Using it this way gives an
even spread of instances over the compute nodes up to a point the
compute cores are filled up evenly, then it overflows to the compute
nodes with more CPU cores. Maybe it is possible to achieve the same
with existing filters, at the time I did not see how.


Hi Mikhail,

Did you mean to say you created a new *weigher*, not filter?

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Mikhail Medvedev]

On Sun, Apr 29, 2018 at 4:29 PM, Ed Leafe  wrote:
>
> Another data point that might be illuminating is: how many sites use a custom 
> (i.e., not in-tree) filter or weigher? One of the original design tenets of 
> the scheduler was that we did not want to artificially limit what people 
> could use to control their deployments, but inside of Nova there is a lot of 
> confusion as to whether anyone is using anything but the included filters.
>
> So - does anyone out there rely on a filter and/or weigher that they wrote 
> themselves, and maintain outside of OpenStack?
>

Internal cloud that is used for Power KVM CI single use VMs:

AvailabilityZoneFilter
AggregateMultiTenancyIsolation
RetryFilter
RamFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
CoreFilter
NumInstancesFilter *
NUMATopologyFilter

NumInstancesFilter is a custom weigher I have added that returns
negative number of instances on a host. Using it this way gives an
even spread of instances over the compute nodes up to a point the
compute cores are filled up evenly, then it overflows to the compute
nodes with more CPU cores. Maybe it is possible to achieve the same
with existing filters, at the time I did not see how.

---
Mikhail Medvedev
IBM

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Ed Leafe]

On Apr 29, 2018, at 1:34 PM, Artom Lifshitz  wrote:
> 
> Based on that, we can definitely say that SameHostFilter and
> DifferentHostFilter do *not* belong in the defaults. In fact, we got
> our defaults pretty spot on, based on this admittedly very limited
> dataset. The only frequently occurring filter that's not in our
> defaults is AggregateInstanceExtraSpecsFilter.

Another data point that might be illuminating is: how many sites use a custom 
(i.e., not in-tree) filter or weigher? One of the original design tenets of the 
scheduler was that we did not want to artificially limit what people could use 
to control their deployments, but inside of Nova there is a lot of confusion as 
to whether anyone is using anything but the included filters.

So - does anyone out there rely on a filter and/or weigher that they wrote 
themselves, and maintain outside of OpenStack?

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Matt Riedemann]

On 4/27/2018 4:02 AM, Tomáš Vondra wrote:
Also, Windows host isolation is done using image metadata. I have filled 
a bug somewhere that it does not work correctly with Boot from Volume.


Likely because for boot from volume the instance.image_id is ''. The 
request spec, which the filter has access to, also likely doesn't have 
the backing image metadata for the volume because the instance isn't 
creating with an image directly. But nova could fetch the image metadata 
from the volume and put that into the request spec. We fixed a similar 
bug recently for the IsolatedHostsFilter:


https://review.openstack.org/#/c/543263/

If you can find the bug, or report a new one, I could take a look.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [nova] Default scheduler filters survey

[Tomáš Vondra]

Hi!

What we‘ve got in our small public cloud:

 

scheduler_default_filters=AggregateInstanceExtraSpecsFilter,

AggregateImagePropertiesIsolation,

RetryFilter,

AvailabilityZoneFilter,

AggregateRamFilter,

AggregateDiskFilter,

AggregateCoreFilter,

ComputeFilter,

ImagePropertiesFilter,

ServerGroupAntiAffinityFilter,

ServerGroupAffinityFilter

 

#ComputeCapabilitiesFilter off because of conflict with 
AggregateInstanceExtraSpecFilter https://bugs.launchpad.net/nova/+bug/1279719

 

I really like to set resource limits using Aggregate metadata.

Also, Windows host isolation is done using image metadata. I have filled a bug 
somewhere that it does not work correctly with Boot from Volume. I believe it 
got pretty much ignored. That’s why we also use flavor metadata.

 

Tomas from Homeatcloud

 

From: Massimo Sgaravatto [mailto:massimo.sgarava...@gmail.com] 
Sent: Saturday, April 21, 2018 7:49 AM
To: Simon Leinen
Cc: OpenStack Development Mailing List (not for usage questions); OpenStack 
Operators
Subject: Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler 
filters survey

 

enabled_filters = 
AggregateInstanceExtraSpecsFilter,AggregateMultiTenancyIsolation,RetryFilter,AvailabilityZoneFilter,RamFilter,CoreFilter,AggregateRamFilter,AggregateCoreFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

 

Cheers, Massimo

 

On Wed, Apr 18, 2018 at 10:20 PM, Simon Leinen  wrote:

Artom Lifshitz writes:
> To that end, we'd like to know what filters operators are enabling in
> their deployment. If you can, please reply to this email with your
> [filter_scheduler]/enabled_filters (or
> [DEFAULT]/scheduler_default_filters if you're using an older version)
> option from nova.conf. Any other comments are welcome as well :)

We have the following enabled on our semi-public (academic community)
cloud, which runs on Newton:

AggregateInstanceExtraSpecsFilter
AvailabilityZoneFilter
ComputeCapabilitiesFilter
ComputeFilter
ImagePropertiesFilter
PciPassthroughFilter
RamFilter
RetryFilter
ServerGroupAffinityFilter
ServerGroupAntiAffinityFilter

(sorted alphabetically) Recently we've also been trying

AggregateImagePropertiesIsolation

...but it looks like we'll replace it with our own because it's a bit
awkward to use for our purpose (scheduling Windows instance to licensed
compute nodes).
-- 
Simon.


___
OpenStack-operators mailing list
openstack-operat...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev