Bug 1118335

Summary: generated answer file has duplicate keys
Product: [Retired] oVirt Reporter: Yedidyah Bar David <didi>
Component: ovirt-engine-installerAssignee: Simone Tiraboschi <stirabos>
Status: CLOSED CURRENTRELEASE QA Contact: Petr Matyáš <pmatyas>
Severity: low Docs Contact:
Priority: low    
Version: 3.5CC: bugs, gklein, iheim, rbalakri, sbonazzo, yeylon
Target Milestone: ---   
Target Release: 3.5.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: integration
Fixed In Version: ovirt-3.5.0_rc2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-21 16:05:52 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 Yedidyah Bar David 2014-07-10 13:07:38 UTC
Description of problem:

Answer file generated by engine-setup sometimes has duplicate entries. A notable example is current master code with engine/dwh/reports all on a single host - engine db creds appear three times (once for each), dwh creds appear twice (once for each of dwh and reports).

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:

Not sure that just preventing duplicates is enough (as we already did for the summary) - iirc in the past we also had real, conflicting entries (two plugins that unknowingly used the same key for different purposes). We might want to somehow verify that any such duplicates (in the code) are intended.

Additional info:

Comment 1 Simone Tiraboschi 2014-09-08 16:53:14 UTC
The answerfile is written in a single step getting checking all the variables in the environment parsing the constants modules. For each key we can have a single value in the environment so I don't think we can have multiple values in the answerfile, while instead we can had multiple copies of the same key value pair if we had different constants pointing to that.

Comment 2 Yedidyah Bar David 2014-09-09 05:46:42 UTC
(In reply to Yedidyah Bar David from comment #0)
> Not sure that just preventing duplicates is enough (as we already did for
> the summary) - iirc in the past we also had real, conflicting entries (two
> plugins that unknowingly used the same key for different purposes). We might
> want to somehow verify that any such duplicates (in the code) are intended.
> 

(In reply to Simone Tiraboschi from comment #1)
> The answerfile is written in a single step getting checking all the
> variables in the environment parsing the constants modules. For each key we
> can have a single value in the environment so I don't think we can have
> multiple values in the answerfile, while instead we can had multiple copies
> of the same key value pair if we had different constants pointing to that.

You are obviously right.

The only explanation I have for my vague memories is that perhaps I saw somewhere (QE?) an answer file which was written with duplicate keys and later was edited to have also different values for the same (duplicate) key. So not duplicating keys will also help prevent such errors.

We still might want to try and prevent such unintended duplicate keys in the code, but that's a different matter (and bug, if at all).

Comment 3 Simone Tiraboschi 2014-09-10 09:21:49 UTC
The key list to be wrote in the answerfile is generated at runtime parsing the constant list.
So if we have, and we have, two distinct constants that represent the same key it's going to duplicate it. This patch just prevent it to avoid further confusion editing the file  as you pointed out.
If the interface is the key and not the constant name on my opinion they are not real bugs.

Comment 4 Yedidyah Bar David 2014-09-10 11:40:47 UTC
(In reply to Simone Tiraboschi from comment #3)
> The key list to be wrote in the answerfile is generated at runtime parsing
> the constant list.
> So if we have, and we have, two distinct constants that represent the same
> key it's going to duplicate it. This patch just prevent it to avoid further
> confusion editing the file  as you pointed out.
> If the interface is the key and not the constant name on my opinion they are
> not real bugs.

But if it was unintended? Two constants pointing to same string but unintentionally? Each "thinking" he is the sole user of this key and they are stepping on each other? See e.g. bug #1051831 - not a real example but same concern.

It might make sense to add to osetupattrs a param say 'shared', false by default, and have a loop over the constants files that alerts if there are duplicate keys that are not all with 'shared=True'.

Comment 5 Sandro Bonazzola 2015-01-21 16:05:52 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.