Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler filters survey
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 > 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-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
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
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-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
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
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
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
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-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [nova] Default scheduler filters survey
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
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
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
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
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
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-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
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
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