Running Cudet to check customizations of an env fails with "[ERROR] Could't load databases." error

[Dmitriy Kruglov]

Detailed bug description:
Executing cudet tool for checking if an env has been customized fails with "[ERROR] Could't load databases." error.

Steps to reproduce:
1 Deploy a 9.1 cluster, e.g. 1 controller + 1 compute + 1 cinder nodes
2 Install Cudet
  yum install -y python-cudet
3 Run the tool against env or node
  cudet -n <NODE_ID>

Expected result: the tool is executed and reports the env customizations if any.
Actual result: command execution returns "[ERROR] Could't load databases." error.

Cudet output with enabled debug: http://pastebin.com/VHstf6rd

Description of the environment:
MOS 9.1, snapshot #284

[Dmitriy Kruglov (dkruglov)]

Additional details:
The root cause is that cudet looks for repository report in http://mirror.fuel-infra.org/mcv/mos/.
And for a particular release the report is supposedly to be published after the release itself (e.g. 9.1).

Still it is not OK that cudet fails to operate because of non-existing url. This way the other checks to be performed by cudet are blocked (e.g. md5 verification of file changes on nodes, etc.)
The proper way in this case would be to continue operating and in the command output/report notify in the corresponding section that cudet failed to access release report via the corresponding url.

[Maksim Malchuk (mmalchuk)]

please provide the diagnostic snapshot

[Dmitry Kalashnik (dkalashnik)]

Failed job https://product-ci.infra.mirantis.net/job/9.x.system_test.ubuntu.env_customizations_check/3/

[Vitaly Sedelnik (vsedelnik)]

It's expected behavior that cudet fails if unable to load database. In the comment #1 you are actually asking to fail in different way. There is also workaround to upload database locally so cudet will use it instead of downloading from the mirror. You should use this workaround in your test scenarios.

Because of above reasons I am downgrading it from Critical to Low, see below the definitions:
- Critical: Data corruption / complete failure affecting most users, no workaround
- Low: Small issue with an easy workaround

Also retargeting to 9.2 because of Low importance.

[Dmitriy Kruglov (dkruglov)]

It's not a trivial workaround if it assumes patching code on fuel master on the fly in the test.
Anyway, thank you for the update.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/374737

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dmitriy Kruglov (<email address hidden>) on branch: stable/mitaka
Review: https://review.openstack.org/374737
Reason: No longer needed.

[Denis Meltsaykin (dmeltsaykin)]

Since 9.1 is released and the database is published as well, I'm going to close the issue as Invalid.