Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1867049

Summary: nova-event-callback validation error messages aren't helpful
Product: Red Hat OpenStack Reporter: Cédric Jeanneret <cjeanner>
Component: openstack-tripleo-validationsAssignee: Artom Lifshitz <alifshit>
Status: CLOSED DUPLICATE QA Contact: nlevinki <nlevinki>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.1 (Train)CC: jjoyce, jschluet, slinaber, stephenfin, tvignaud
Target Milestone: z3Keywords: Triaged, ZStream
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-02 17:21:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Cédric Jeanneret 2020-08-07 09:06:12 UTC
Hello,

The error messages provided by the "nova_event_callback" role aren't really helpful. Some doc link or, at least, better wording might be good in order to guide the operator.

For instance, what should be done in order to avoid this:
failed: [oc0-controller-0] (item={'msg': "The key 'vif_plugging_timeout' under the section 'DEFAULT' in file /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf has the value: '300'", 'changed': False, 'value': '300', 'invocation': {'module_args': {'path': '/var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf', 'section': 'DEFAULT', 'key': 'vif_plugging_timeout', 'ignore_missing_file': True, 'default': None}}, 'failed': False, 'item': 'vif_plugging_timeout', 'ansible_loop_var': 'item'}) => {"ansible_loop_var": "item", "changed": false, "item": {"ansible_loop_var": "item", "changed": false, "failed": false, "invocation": {"module_args": {"default": null, "ignore_missing_file": true, "key": "vif_plugging_timeout", "path": "/var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf", "section": "DEFAULT"}}, "item": "vif_plugging_timeout", "msg": "The key 'vif_plugging_timeout' under the section 'DEFAULT' in file /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf has the value: '300'", "value": "300"}, "msg": "Value of vif_plugging_timeout is set to 300."}

Thank you!

Cheers,

C.

Comment 1 Artom Lifshitz 2020-08-20 22:03:42 UTC
Maybe this is obvious to someone who understand the deployment framework (which I don't, I'm a Nova dev), but when does this error message happen? Fully filling out the new BZ template might be helpful here.

Comment 2 Cédric Jeanneret 2020-08-21 07:00:53 UTC
Hello Artom,

Nothing to do with the deployment framework, but with the validations:
https://github.com/openstack/tripleo-validations/blob/master/roles/nova_event_callback/tasks/main.yml

For instance, the message here:
https://github.com/openstack/tripleo-validations/blob/master/roles/nova_event_callback/tasks/main.yml#L61
is unclear:
- what is expected?
- how can we change this value?

Cheers,

C.

Comment 3 Artom Lifshitz 2020-08-21 11:08:27 UTC
Ah, thanks Cedric, that helps!

Looks like the error message from the bug description is referring to this bit of code [1]. There's a logic error on L19, it makes no sense to throw an error if `vif_plugging_timeout_check <= vif_plugging_timeout_value_min`, it should be `vif_plugging_timeout_check < vif_plugging_timeout_value_min` (notice the strictly less than). Otherwise you get the error message from the original bug description, complaining that vif_plugging_timeout is set to 300, when 300 is the default value. Also the whole [1] block of code is weird. Why iterate over items when there's only 2 of them, and each has a different validation logic. Have one task that checks that `vif_plugging_timeout_check` is no smaller than 300 (and an error msg to that effect), and another task that `vif_plugging_fatal_check` is True (with a different error message to that effect).

Side note - I'm not really sure these are valid validations. The default values of True and 300 are there for a reason, they should work in the majority of cases, but there could be valid reasons to change either one of them.

As for the block of code in [2], looks like it's just making sure `notify_nova_on_port_data_check` and `notify_nova_on_port_status_check` are set to True. I agree that it's confusing - the msg on L61 should be something like "{{ item.item }} should be set to True. Current value: {{ item.value }}."

[1] https://github.com/openstack/tripleo-validations/blob/master/roles/nova_event_callback/tasks/main.yml#L14-L21
[2] https://github.com/openstack/tripleo-validations/blob/master/roles/nova_event_callback/tasks/main.yml#L47-L63

Comment 4 Artom Lifshitz 2020-08-21 18:45:00 UTC
I've proposed https://review.opendev.org/747464 and https://review.opendev.org/#/c/747463/1. As these are my first patches in tripleo-validations I've probably done something wrong, but it's a start.

Comment 5 Cédric Jeanneret 2020-08-24 05:45:42 UTC
Thanks Artom! Patches look good to me :)

Comment 7 Artom Lifshitz 2020-08-25 13:51:29 UTC
Thanks for the upstream reviews Cedric! Can we close this out as UPSTREAM, or would you like backports to older branches?

Comment 8 Cédric Jeanneret 2020-08-25 14:04:26 UTC
Hello Artom,

If it's OK for you, it would be really great having them down to train (osp-16.1) so that the LTS OSP can profit of this improvement :). Care to manage the backports?

Cheers,

C.

Comment 11 Artom Lifshitz 2020-11-02 17:21:54 UTC

*** This bug has been marked as a duplicate of bug 1891197 ***