Bug 1118335 - generated answer file has duplicate keys
Summary: generated answer file has duplicate keys
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer
Version: 3.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 3.5.1
Assignee: Simone Tiraboschi
QA Contact: Petr Matyáš
URL:
Whiteboard: integration
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-10 13:07 UTC by Yedidyah Bar David
Modified: 2015-01-21 16:05 UTC (History)
6 users (show)

Fixed In Version: ovirt-3.5.0_rc2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:05:52 UTC
oVirt Team: ---


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 32654 master MERGED packaging: setup: avoid duplicate keys in answerfile Never
oVirt gerrit 32655 ovirt-engine-3.5 MERGED packaging: setup: avoid duplicate keys in answerfile Never

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.


Note You need to log in before you can comment on or make changes to this bug.