On Fri, Dec 21, 2018 at 10:10 PM Nir Soffer <nsoffer@redhat.com> wrote:


On Fri, Dec 21, 2018, 07:42 Germano Veit Michel <germano@redhat.com wrote:
Hi,

With these 2 changes the ovirt-log-collector will collect storage domain metadata from all storage domains of the environment in a more efficient way.

Can you exolain how using sqlite is more efficient than the text/json format?

We discussed this in https://gerrit.ovirt.org/#/c/88109/, you suggested sqlite so we don't have to write a tool to easily search/visualize the metadata.
I think sqlite is the easiest way, json requires additional tools to parse/read/search and text is simply unsuitable for this task. The current text output misses several fields and the format may change, parsing text is not efficient.
 

Also ignoring the storage domain argument and collecting info for all domains looks like the wrong approach, as we are more likely to time out an fail the entire operation.

Yes it can happen. In fact it already happens today. In those cases we just ask to collect manually, no big deal if it fails and it shouldn't prevent us from coding more automated collection of this. What we need is this: https://bugzilla.redhat.com/show_bug.cgi?id=1557147
 
Can you describe the use cases that you are trying to solve?

Quite a few: today support needs to ask for storage domain metadata manually (i.e. dd if=/dev/sd/metadata) to fix LSM/Snapshot cases. The idea is to place a sqlite database in the log-collector folder, next to the engine database (not on some random host sosreport) and have a tool to match both databases, pointing to possible issues. Support can easily use sqlite3 from command line on the storage domain sqlite3 database to check what is required to fix the LSM/Snapshot issue. And also serves for us to reduce the back and forth requesting data on support cases. Also this can be consumed by the analyzer that runs automatically these days once a customer uploads logs. 
 

Nir




I'll be away for the next 2 weeks, but reviews are welcome. If there is any problem with one of these patches, please don't merge any of them as they require each other.

And if you have extra time, reviews are welcome on this series too =D

Thanks,
Germano
_______________________________________________
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/6VES5SCZ46H3OMHRZ3FR4VRKDKHCDS4Q/