I don't see RetryFilter being enabled by default in any templates on the Wallaby branch? Do you see it enabled in your templates by default?
Or, do you mean that you're adding it to NovaSchedulerEnabledFilters: in one of your environment files and then nova-scheduler is failing?

If the latter is the case, I don't believe that would be a bug, we would allow users to specify any filters they like. But we can let dfg:compute weigh in on that.

(In reply to Brendan Shephard from comment #1)
> I don't see RetryFilter being enabled by default in any templates on the
> Wallaby branch? Do you see it enabled in your templates by default?
> Or, do you mean that you're adding it to NovaSchedulerEnabledFilters: in one
> of your environment files and then nova-scheduler is failing?
> 
> If the latter is the case, I don't believe that would be a bug, we would
> allow users to specify any filters they like. But we can let dfg:compute
> weigh in on that.

Hi Brendan,
so in my job, I am using infrared parameter set-nova-scheduler-filter {https://github.com/redhat-openstack/infrared/blob/master/plugins/tripleo-overcloud/vars/overcloud/templates/set-nova-scheduler-filter.yml}
and as you can see it include the RetryFilter.
You are right that it's a user's wrong input but from my point of view as QE when the user provides incorrect THT/configuration, we have to block/ fail his/her deployment.
In that case I provided the wrong that and the deployment passed.

Hey,

Yeah, I see where you're coming from. But I believe it's possible to use custom Nova filters, for example, like we do with TripleO in Queens/Train with Tripleo Capabilities Filter:
https://github.com/openstack/tripleo-common/blob/stable/train/tripleo_common/filters/capabilities_filter.py

If we restrict this to n number of filters, we will be limiting the customers ability to use Nova features. I think we should let dfg:compute rule on this though and see what they say, maybe we don't want to support users with custom scheduler filters.

(In reply to Brendan Shephard from comment #3)
> Hey,
> 
> Yeah, I see where you're coming from. But I believe it's possible to use
> custom Nova filters, for example, like we do with TripleO in Queens/Train
> with Tripleo Capabilities Filter:
> https://github.com/openstack/tripleo-common/blob/stable/train/tripleo_common/
> filters/capabilities_filter.py
> 
> If we restrict this to n number of filters, we will be limiting the
> customers ability to use Nova features. I think we should let dfg:compute
> rule on this though and see what they say, maybe we don't want to support
> users with custom scheduler filters.

I am adding 2 compute DFG members for more thoughts

The user can create custom filters and we allow them to be used vai a supprot excption
so form a compute dfg point of view i do not think it would be correct to limit this in THT.

a validation pre-check/validation coudl be created for people upgrading but we should not block this via the tht parmater in my view.
it should really just be a warning. while unlikely that someone will create a custom filter called RetryFilter it should still be possibel to
do so and deploy it. we also shoudl not need to update validation in ooo every time we remove filters. the rety filter is not the first filter we have removed
in the past we have alwasy just removed it form the default tepmpeltes after it was deprecated in nova.

(In reply to smooney from comment #5)
> The user can create custom filters and we allow them to be used vai a
> supprot excption
> so form a compute dfg point of view i do not think it would be correct to
> limit this in THT.
> 
> a validation pre-check/validation coudl be created for people upgrading but
> we should not block this via the tht parmater in my view.
> it should really just be a warning. while unlikely that someone will create
> a custom filter called RetryFilter it should still be possibel to
> do so and deploy it. we also shoudl not need to update validation in ooo
> every time we remove filters. the rety filter is not the first filter we
> have removed
> in the past we have alwasy just removed it form the default tepmpeltes after
> it was deprecated in nova.

smooney the point is that we allow the customers to use templates that will not fail the deployment but will cause problems in the system, 
like I faced when I enabled the RetryFilter the deployment passed but nova-scheduler did not run on the system.

Please note that deployment framework provides no control for user inputs but listing allowed values, whenever applicable.
Improvements should be done to the validations framework to cover upgrade cases impacted by the removed RetryFilter.

Moving to DFG:Upgrades as this needs a validation from Upgrades, not an adjustment of the framework, IMHO.
if I am wrong, give me a shout.
Jan

Understood that we need to take care somehow of the RetryFilter before upgrading from 16 to 17.

Hi,

so after another at this, what I understand is that:
 1. RetryFilter is removed is OSP17;
 2. We could implement a validation that output a Warning if the RetryFilter is in the OSP17 configuration:
    - warning not error in the unlikely but possible chance that the user created a custom RetryFilter
 3. When RetryFilter is defined and doesn't exist nova-scheduler crash.

So 2. should be implemented by Compute as they see fit, upgrade cannot really tackle this as:
 - there is not clear way yet to test osp16->17
 - Compute will have far more knowledge about how to do that :)

But, I think that 3. could be solved.  Maybe a this should be warning in the nova-scheduler instead of a "silent" (from the user point of view) error.

Furthermore, it seems to me that having a successful deployment with a failed service is a issue on its own and that should be fixed.

So, problem 2. would be for Compute, and 3. Compute/DF ?

WDYT: @smooney , @bdobreli 

Overall Compute DFG seems the most appropriate place to land this.

I think we (like compute with DF/validations teams) should provide a pre-overcloud-prepare validation interface to look for some data patterns in the --templates path used with the deployment command. That interface, once provided, could address the point #2 in above comment

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:6543