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

[Dave Holland]

Thanks Tim, pre-emptible instances are definitely of interest too. I'll
be in Vancouver, hope to meet up at some point.

And thanks Mathieu for sharing the code, if we build anything of wider
interest I'll try to get it shared.

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


On Tue, May 01, 2018 at 01:10:56PM +, Tim Bell wrote:
> 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 <d...@sanger.ac.uk>
> Date: Tuesday, 1 May 2018 at 10:40
> To: Mathieu Gagné <mga...@calavera.ca>
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-...@lists.openstack.org>, openstack-operators 
> <openstack-operators@lists.openstack.org>
> 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-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 



-- 
 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-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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 <d...@sanger.ac.uk>
Date: Tuesday, 1 May 2018 at 10:40
To: Mathieu Gagné <mga...@calavera.ca>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-...@lists.openstack.org>, openstack-operators 
<openstack-operators@lists.openstack.org>
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-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


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

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

[Dave Holland]

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-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Artom Lifshitz]

Thanks everyone for your input!

I wrote a small Python script [1] to present all your responses in an
understandable format. Here's the output:

Filters common to all deployments: {'ComputeFilter',
'ServerGroupAntiAffinityFilter'}

Filter counts (out of 9 deployments):
ServerGroupAntiAffinityFilter9
ComputeFilter9
AvailabilityZoneFilter   8
ServerGroupAffinityFilter8
AggregateInstanceExtraSpecsFilter8
ImagePropertiesFilter8
RetryFilter  7
ComputeCapabilitiesFilter5
AggregateCoreFilter  4
RamFilter4
PciPassthroughFilter 3
AggregateRamFilter   3
CoreFilter   2
DiskFilter   2
AggregateImagePropertiesIsolation2
SameHostFilter   2
AggregateMultiTenancyIsolation   1
NUMATopologyFilter   1
AggregateDiskFilter  1
DifferentHostFilter  1

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.

[1] https://gist.github.com/notartom/0819df7c3cb9d02315bfabe5630385c9

On Fri, Apr 27, 2018 at 8:10 PM, Lingxian Kong  wrote:
> At Catalyst Cloud:
>
> RetryFilter
> AvailabilityZoneFilter
> RamFilter
> ComputeFilter
> AggregateCoreFilter
> DiskFilter
> AggregateInstanceExtraSpecsFilter
> ImagePropertiesFilter
> ServerGroupAntiAffinityFilter
> SameHostFilter
>
> Cheers,
> Lingxian Kong
>
>
> On Sat, Apr 28, 2018 at 3:04 AM Jim Rollenhagen 
> wrote:
>>
>> On Wed, Apr 18, 2018 at 11:17 AM, Artom Lifshitz 
>> wrote:
>>>
>>> Hi all,
>>>
>>> A CI issue [1] caused by tempest thinking some filters are enabled
>>> when they're really not, and a proposed patch [2] to add
>>> (Same|Different)HostFilter to the default filters as a workaround, has
>>> led to a discussion about what filters should be enabled by default in
>>> nova.
>>>
>>> The default filters should make sense for a majority of real world
>>> deployments. Adding some filters to the defaults because CI needs them
>>> is faulty logic, because the needs of CI are different to the needs of
>>> operators/users, and the latter takes priority (though it's my
>>> understanding that a good chunk of operators run tempest on their
>>> clouds post-deployment as a way to validate that the cloud is working
>>> properly, so maybe CI's and users' needs aren't that different after
>>> all).
>>>
>>> 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 :)
>>
>>
>> At Oath:
>>
>> AggregateImagePropertiesIsolation
>> ComputeFilter
>> CoreFilter
>> DifferentHostFilter
>> SameHostFilter
>> ServerGroupAntiAffinityFilter
>> ServerGroupAffinityFilter
>> AvailabilityZoneFilter
>> AggregateInstanceExtraSpecsFilter
>>
>> // jim
>>
>> __
>> 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
>



-- 
--
Artom Lifshitz
Software Engineer, OpenStack Compute DFG

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

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

[Jim Rollenhagen]

On Wed, Apr 18, 2018 at 11:17 AM, Artom Lifshitz 
wrote:

> Hi all,
>
> A CI issue [1] caused by tempest thinking some filters are enabled
> when they're really not, and a proposed patch [2] to add
> (Same|Different)HostFilter to the default filters as a workaround, has
> led to a discussion about what filters should be enabled by default in
> nova.
>
> The default filters should make sense for a majority of real world
> deployments. Adding some filters to the defaults because CI needs them
> is faulty logic, because the needs of CI are different to the needs of
> operators/users, and the latter takes priority (though it's my
> understanding that a good chunk of operators run tempest on their
> clouds post-deployment as a way to validate that the cloud is working
> properly, so maybe CI's and users' needs aren't that different after
> all).
>
> 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 :)
>

At Oath:

AggregateImagePropertiesIsolation
ComputeFilter
CoreFilter
DifferentHostFilter
SameHostFilter
ServerGroupAntiAffinityFilter
ServerGroupAffinityFilter
AvailabilityZoneFilter
AggregateInstanceExtraSpecsFilter

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

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [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 <simon.lei...@switch.ch> 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-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

 

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

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

[Massimo Sgaravatto]

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-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Simon Leinen]

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-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators